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Preface 


The  following  document  is  the  culmination  of  the  work  performed  by  a  team  of 
eight  graduate  engineering  students  assigned  to  the  Air  Force  Institute  of  Technology 
(AFIT).  The  students  compiled  this  document  while  performing  a  systems  engineering 
design  study  to  create  a  small  standardized  tactical  satellite  bus  for  the  Phillips 
Laboratory.  This  document  is  divided  into  three  separate  volumes.  Each  volume  is  an 
integrated  element  of  the  student  thesis  but  it  can  also  serve  as  a  stand  alone  document. 

The  first  volume  is  the  Executive  Summary.  The  purpose  of  the  Executive 
Summary  is  to  present  a  synopsis  of  the  design  study  results  to  the  sponsor  at  the  Phillips 
Laboratory.  This  volume  includes  information  on  the  methods  employed  during  the  study, 
the  scope  of  the  problem,  the  value  system  used  to  evaluate  alternatives,  tradeoff  studies 
performed,  modeling  tools  utilized  to  create  and  analyze  design  alternatives, 
recommendations  and  implications  of  the  alternatives,  and  areas  where  future  research 
should  be  considered. 

The  second  volume  is  a  detailed  account  of  the  design  process.  The  steps  of  the 
team’s  iimovative  design  process  and  the  team  organization  are  initially  presented.  Each 
phase  of  the  design  study  is  discussed  in  subsequent  sections.  Phase  I  provides  accounts 
of  the  team’s  initial  attempt  to  apply  a  well  known  systematic  approach  to  satellite  design. 
EiBforts  concentrate  on  defining  the  problem  posed  by  the  sponsor.  ‘Tirst  cuts”  at 
developing  analysis  tools  and  models  are  performed.  Additionally,  different  alternatives 
are  generated  as  possible  solutions  to  the  problem.  An  initial  analysis  and  evaluation  is 
performed  to  define  an  initial  solution  space,  and  to  verify  the  analysis  tool.  Phase  II  is  an 
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iterative  step  in  the  design  process  and  serves  as  a  reservoir  for  the  team’s  most 
meaningful  work.  The  team  realized  that  a  new  systematic  approach  had  to  be  applied  to 
the  study.  This  phase  provides  the  results  of  the  application  of  that  innovative  approach. 

It  is  here  that  the  understanding  of  the  problem  is  fiirther  refined  and  decisions  are  made 
that  limit  the  scope  of  the  study.  The  objective  hierarchy  is  further  developed  and  a  value 
system  is  created  as  a  method  for  measuring  each  design  alternative.  Information  is 
collected  on  satellite  designs  and  satellite  subsystems.  Tradeoffs  are  performed  to 
determined  the  best  methods  and  components  to  be  used  in  the  alternatives.  A  model  is 
created  and  design  alternatives  are  generated.  System  analysis  is  performed  on  the 
alternatives  using  the  value  hierarchy,  and  results  are  generated.  Sensitivity  analysis  is 
performed  on  the  alternatives,  and  implementation  recommendations  are  provided  to  the 
sponsor. 

The  third  volume  provides  details  on  the  tools  developed  to  build  a  satellite  and  to 
analyze  the  design.  There  are  three  sections  to  this  volume.  The  first  section  describes  the 
model’s  philosophy  and  presents  details  on  the  purpose  and  operation  of  each  module  of 
the  model.  Mathematical  formulae  and  module  architecture  are  also  described  in  this 
section.  The  second  section  is  a  user’s  guide  to  operating  the  model.  Specific  details  of 
the  sequence  to  be  used  and  information  required  to  run  the  model  are  provided  in  this 
discussion.  The  final  section  of  this  volume  is  the  actual  code  of  the  model.  The  code  is 
contained  in  an  annex  and  is  maintained  by  AFIT’s  Aeronautics  Department  at  Wright- 
Patterson  AFB,  Ohio.  The  code  can  be  provided  to  allow  future  modelers  to  understand 
and  refine  the  work  that  has  been  accomplished. 
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Abstract 

A  PRELIMINARY  DESIGN  OF  A  STANDARDIZED  SPACECRAFT  BUS  FOR 

SMALL  TACTICAL  SATELLITES 

Current  satellite  design  philosophies  concentrate  on  optimizing  and  tailoring  a  particular 
satellite  bus  to  a  specific  payload  or  mission.  Today's  satellites  take  a  long  time  to  build, 
checkout,  and  launch.  Space  Operations  planners,  concerned  with  the  unpredictable 
nature  of  the  global  demands  placed  upon  space  systems,  desire  responsive  satellite 
systems  that  are  multi-mission  capable,  easily  and  inexpensively  produced,  smoothly 
integrated,  and  rapidly  launched.  This  emphasis  shifl;s  the  design  paradigm  to  one  that 
focuses  on  access  to  space,  enabling  tactical  deployment  on  demand  and  the  capability  to 
put  current  payload  technology  into  orbit,  versus  several  years  by  today's  standards,  by 
which  time  the  technology  is  already  obsolete.  This  design  study  applied  systems 
engineering  methods  to  create  a  satellite  bus  architecture  that  can  accommodate  a  range  of 
remote  sensing  mission  modules.  System-level  and  subsystem-level  tradeoffs  provided 
standard  components  and  satellite  structures,  and  an  iterative  design  approach  provided 
candidate  designs  constructed  with  those  components.  A  cost  and  reliability  trade  study 
provided  initial  estimates  for  satellite  performance.  Modeling  and  analysis  based  upon  the 
Sponsor’s  objectives  converged  the  designs  to  an  optimum  solution.  Optimum  design 
characteristics  include  a  single-string  architecture,  modular  solar  arrays,  an  internet-style 
command  and  data  handling  system,  on-board  propulsion,  and  a  cage  structure  with  a 
removable  fi'ame  for  easy  access  to  subsystem  components.  Major  products  of  this  study 
include  not  only  a  preliminary  satellite  design  to  meet  the  sponsor’s  needs,  but  also  a 
software  modeling  and  analysis  tool  for  satellite  design,  integration,  and  test.  FinaUy,  the 
report  provides  an  initial  implementation  scheme  and  concept  for  operations  for  the 
tactical  support  of  this  satellite  system. 
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1.  Report  Overview 


This  document  provides  the  results  of  a  group  design  study  performed  at  the  Air 
Force  Institute  of  Technology.  The  team  of  eight  graduate  engineering  students  examined 
the  design  of  a  generic,  standardized  spacecraft  bus  for  small  tactical  satellites.  The  project 
was  sponsored  by  LtCol  James  Rooney  of  the  United  States  Air  Force’s  Phillips 
Laboratory  in  Albuquerque,  New  Mexico.  Similar  design  studies  have  been  completed  by 
various  companies  and  laboratories,  but  to  date  success  has  been  limited.  Phillips 
Laboratory’s  goal  was  to  seek  a  “clean-sheet”  approach  to  the  design  of  a  cost-effective 
satellite  bus.  Several  design  characteristics  were  suggested  by  the  sponsor  and  were 
considered  throughout  the  project.  These  characteristics  included  modularity,  flexibility, 
robustness,  and  operability.  These  characteristics  have  been  treated  as  guidance  in 
developing  objectives  and  alternative  design  architectures  and  were  not  treated  as  hard 
requirements. 

This  is  the  second  volume  of  a  three  volume  report.  Volume  I  is  an  Executive 
Summary  of  the  work  performed  by  the  design  team.  Volume  II  provides  greater  detail  of 
the  work  and  includes  the  theory  and  analysis  behind  the  team’s  approach  to  the  problem. 
Volume  in  is  an  in-depth  explanation  of  the  modeling  performed  for  the  project. 

This  volume  is  divided  into  three  sections.  The  first  section  discusses  the  details  of 
the  team’s  design  process  that  was  created  to  approach  the  problem.  The  second  section 
of  this  document.  Phase  I,  records  the  team’s  first  application  of  the  a  systematic  approach 
tq  the  design  study.  Details  are  provided  on  the  initial  methodology  applied  to  the 
problem  and  preliminary  satellite  design  information  is  presented.  The  work  performed  in 
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this  section  of  the  report  established  a  baseline  for  further  iterations  of  the  design  approach 
and  guided  the  team  to  new  areas  of  research. 

Phase  II,  the  third  section,  is  a  repository  for  the  majority  of  the  work  performed 
by  the  design  team.  This  section  documents  the  work  performed  in  the  second  iteration  of 
the  systematic  approach.  During  this  portion  of  the  study,  the  scope  of  the  problem  is 
refined  and  enhancements  are  made  to  the  steps  of  the  design  process.  Different  design 
alternatives  are  presented  and  analyzed  using  the  objective  hierarchy  developed  as  part  of 
the  process.  The  results  of  the  analysis,  and  subsequent  sensitivity  analysis,  are  also 
provided.  The  section  ends  with  a  discussion  of  decision  making  and  the  implementation 
of  the  results. 
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2.  Design  Process 


The  design  team  recognized  the  need  for  a  well-defined,  iterative,  systematic 
design  process  to  approach  the  problem  logically.  The  design  team  was  familiar  with  two 
well-known  systematic  approaches.  Hall’s  seven-step  process  to  systems  engineering 
(Hall,  1969;  156)  and  the  space  mission  design  approach  described  in  the  Space  Mission 
Analysis  and  Design  (SMAD)  textbook  (Wertz  and  Larson,  1992: 1). 

Hall’s  systematic  process  has  been  a  standard  systematic  approach  for  almost  four 
decades.  This  process  is  well  understood  and  can  be  applied  to  many  different  engineering 
problems.  The  Hall  method  is  an  iterative  seven-step  process  (refer  to  Figure  2-1).  These 
steps  are:  problem  definition,  value  system  design,  system  synthesis,  system  analysis, 
optimization,  decision-making  and  implementation  (Hall,  1969:157). 


Figure  2-1:  Hall's  Seven-step  Approach 
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Each  step  of  Hall’s  approach  is  influenced  by  the  actions  taken  in  the  other  steps. 
The  process’  iterative  nature  forces  refinement  in  each  step  as  the  process  continues. 

Hall’s  fundamental  framework  follows  a  logical  sequence  that  allows  the  user  to  define 
and  constrain  the  problem,  create  an  evaluation  tool  using  the  decision-maker’s  values, 
and  generate  possible  solution  alternatives.  The  framework  also  permits  the  user  to  create 
models  and  perform  simulations  as  a  means  of  quantifying  aspects  for  each  alternative. 

The  quantified  values  serve  as  an  input  into  the  evaluation  tool.  Once  the  basic  modeling 
is  accomplished,  diflferent  aspects  of  each  possible  solution  are  further  refined  in  an 
attempt  to  optimize  each  alternative.  Hall’s  process  also  allows  the  user  to  perform 
sensitivity  analysis  on  each  of  the  alternatives  before  the  decision-maker  is  presented  with 
the  results  of  the  system  evaluation.  In  the  decision-making  step,  the  decision-maker 
applies  his  subjective  values  and  risk  preferences  to  select  an  alternative.  With  an 
alternative  selected,  a  plan  for  implementation  is  created.  The  Hall  process  is  complete 
once  an  adequate  implementation  strategy  is  accepted  by  the  decision-maker. 

The  SMAD  approach  is  well-known  to  contemporary  satellite  designers  (Warner, 
1996).  The  SMAD  text  and  the  process  it  describes  is  a  compilation  of  the  first  thirty 
years  of  satellite  design  experience.  In  general  terms,  the  SMAD  process  can  be 
considered  the  classic  approach  to  satellite  design  because  the  approach  is  based  on  the 
premise  that  the  satellite’s  mission  drives  the  design  of  the  satellite  bus.  The  SMAD 
approach  is  iterative  and  consists  of  four  broad  areas.  These  broad  areas  are  1)  define 
objectives,  2)  characterize  the  mission,  3)  evaluate  the  mission,  and  4)  define  requirements 
(Wertz  and  Larson,  1992:2). 
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Table  2-1:  Space  Mission  Analysis  and  Design  Process 


Sub-steps  I 

Define  Objectives 

A.  Define  broad  objectives  and  constraints 

B.  Estimate  quantitative  mission  needs  and  requirements 

Characterize  the  Mission 

C.  Define  alternative  mission  concepts 

D.  Define  alternative  mission  architectures 

E.  Identify  system  drivers  for  each 

F.  Characterize  mission  concepts  and  architectures 

Evaluate  the  Mission 

G.  Identify  driving  requirements 

H.  Evaluate  mission  utility 

I.  Define  mission  concept  (baseline) 

Define  Requirements 

J.  Define  system  requirements 

K.  Alocate  requirements  to  system  elements 

The  first  step  in  the  SMAD  process  is  to  define  the  broad  mission  objectives  and 
constraints.  Additionally,  quantified  estimates  of  how  well  one  wants  to  achieve  the  broad 
mission  objectives  are  developed  with  respect  to  the  needs,  constraints,  and  technology 
available.  These  estimates  become  initial  system  requirements.  A  unique  feature  of  the 
SMAD  process  is  that  these  quantified  estimates  are  subject  to  trades  as  the  process 
continues.  Characterizing  the  mission  involves  a  number  of  steps.  These  steps  include 
defining  alternative  mission  concepts  and  architectures,  identifying  system  drivers  for  each 
alternative,  and  describing  in  detail  what  the  system  is  and  what  it  does.  Power,  weight, 
and  pointing  budgets  are  developed  in  this  step.  Evaluating  the  mission  forces  the 
designer  to  return  to  the  initial  system  requirements  to  determine  which  requirements 
become  driving  requirements.  Driving  requirements  are  the  items  principally  responsible 
for  determining  the  cost  and  level  of  complexity  of  the  system.  Mission  utility  analysis  is 
also  part  of  this  step  and  this  analysis  quantifies  how  well  the  satellite  design  meets  the 
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system  requirements  and  objectives  as  a  function  of  design  choices.  Evaluation  of  the 
mission  ends  by  choosing  a  baseline  system  design.  The  SMAD  process  ends  by  defining 
requirements.  Broad  objectives  and  constraints  are  translated  into  well-defined,  specific 
system  requirements.  These  numerical  requirements  are  allocated  to  specific  components 
of  the  overall  space  mission  (Wertz  and  Larson,  1992:3-90). 

The  traditional  approaches  are  not  suited  to  designing  a  satellite  bus  that  will 
support  a  variety  of  missions.  This  was  recognized  as  the  study  evolved  and  initial 
iterations  of  the  applied  processes  failed  to  narrow  the  scope  of  the  study.  Specifically, 
Hall’s  approach  does  not  provide  an  effective,  streamlined  method  for  converging  on 
viable  satellite  design  alternatives.  Time  is  wasted  performing  numerous  iterations  of  the 
process  to  achieve  the  desired  focus.  Likewise,  the  SMAD  process  concentrates  too 
much  on  using  the  satellite’s  payload  (mission  module)  as  the  key  upon  which  the  satellite 
bus  is  designed.  Consequently,  neither  of  these  methods  is  adequate  for  designing  a 
generic,  standardized  satellite  bus.  A  new,  customized  approach  was  developed  that 
permitted  the  team  to  converge  quickly  on  a  satellite  bus  design  without  regard  to  a 
particular  mission  module  type.  The  systematic  process  that  was  created  is  a  synthesis  of 
the  methods  described  by  Hall  and  SMAD.  The  process  is  called  the  Modsat  approach. 
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Table  2-2:  Modsat  Systems  Approach 


^  Step 

Action  1 

Problem  Definition 

Scope  nature  of  problem 

Value  System  Design 

Capture  decision  maker’s  needs  and  goals;  create 
evaluation  structure  for  alternatives 

Trade  Studies 

Link  broad  design  decisions  directly  to  the  study’s 
goals  and  objectives 

Modeling 

Formulate  predictive  or  descriptive  tool(s)  to 
represent  activities;  analyze  various  configurations  | 

System  Synthesis 

Create  alternative  solution  sets 

System  Analysis 

Score  each  alternative  against  problem’s  evaluation  | 
structure  j 

Decision  Making 

Perform  sensitivity  analysis  on  solution  sets 

1  Implementation 

Develop  plans  for  fielding  the  selected  altemative(s) 

The  iterative  approach  is  comprised  of  eight  steps.  The  steps,  in  order,  are 
problem  definition,  value  system  design,  trade  studies,  modeling,  system  synthesis,  systems 
analysis,  decision-making,  and  implementation.  The  majority  of  these  come  directly  from 
Hall’s  seven-step  process.  The  items  that  distinguish  this  approach  from  Hall’s  approach 
are  the  inclusion  of  a  trade  studies  step  and  the  reordering  of  the  system  synthesis  and 
modeling  steps.  Additionally,  the  design  team’s  approach  does  not  include  an 
optimization  step.  This  process  distinguishes  itself  fi'om  the  SMAD  process  in  two  ways. 
The  systematic  approach  does  not  commit  its  focus  to  the  requirements  of  one  mission 
module  as  the  key  factor  for  satellite  bus  design.  Secondly,  the  process  specifically 
includes  a  method  for  evaluating  the  merits  of  each  design  alternative. 

Problem  definition  is  a  fundamental  first  step  of  any  systematic  process.  The 
Modsat  problem  definition  step  closely  follows  that  of  Hall.  The  purpose  of  this  step  is  to 
define  and  constrain  the  problem.  A  result  of  this  step  is  a  succinct  statement  that 
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identifies  the  goal  and  focus  of  the  study.  The  value  of  the  problem  definition  step  is  that 
it  serves  as  a  mechanism  to  define  the  system  boundaries,  identify  the  system  needs, 
alterables  and  constraints,  and  to  identify  the  system  actors. 

The  system  boundaries  define  the  environment  affecting  the  system.  A  distinction 
can  be  made  between  those  items  contained  within  an  internal  environment  and  those 
items  contained  in  the  external  environment.  Items  within  the  internal  environment  are 
factors  that  the  design  team  can  control.  Items  that  exist  in  the  external  environment 
influence  the  study  but  cannot  be  controlled  by  the  design  team.  The  distinction  between 
the  internal  and  external  environment  is  paramount  to  understanding  the  scope  and  focus 
of  the  project.  The  focus  of  the  study  can  be  narrowed  fiiither  by  performing  iterations  on 
the  system  boundaries.  Needs  are  the  fundamental  requirements  that  the  decision-maker 
and  users  levy  on  the  system  and  are  crucial  in  determining  the  broad  objective  of  the 
study.  As  is  the  case  in  the  SMAD  process,  some  needs  serve  as  driving  requirements  for 
satellite  bus  designs.  Other  needs  may  be  traded  off  against  each  other.  Alterables  are 
those  items  that  can  be  influenced  or  changed  by  the  design  team  and  are  contained  within 
the  internal  environment  of  the  system’s  boundaries.  Constraints  are  those  items  that  the 
team  caimot  control  but  have  a  major  impact  on  focusing  the  study.  Problem  definition 
also  identifies  the  actors  in  the  study.  Actors  are  simply  the  persons/groups  who  influence 
the  design  and  evaluation  of  possible  alternatives.  Different  tools  such  as  concept  maps, 
waterfall  diagrams,  and  interaction  matrices  can  be  used  to  assist  in  defining  the  system 
boundaries,  needs,  alterables,  constraints,  and  actors. 
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The  value  system  design  step  is  similar  to  Hall’s  respective  step.  The  purpose  of 
this  step  is  to  capture  the  decision-maker’s  values  and  goals.  Ultimately,  these  values  and 
goals  are  used  as  a  means  for  evaluating  the  effectiveness  of  design  alternatives. 

Capturing  the  decision-maker’s  values  and  goals  is  accomplished  by  creating  an  objective 
hierarchy.  Broad  values  and  goals  are  translated  into  broad  objectives.  The  broad 
objectives  are  decomposed  into  more  specific  subobjectives  until  meaningful  measures  of 
effectiveness  can  be  determined.  The  study’s  objectives  and  subobjectives  are  related  to 
the  needs,  alterables,  and  constraints  defined  in  the  previous  step.  As  part  of  defining  the 
study’s  objectives  and  measures  of  effectiveness,  major  premises  and  assumptions  are 
explicitly  articulated. 

Once  the  objective  hierarchy  is  in  place  the  decision-maker’s  preferences  for  each 
objective  have  to  be  incorporated  into  the  structure.  It  is  common  to  have  competing 
objectives  for  a  problem  or  study.  A  score,  or  weight,  is  assigned  to  each  objective  per 
level  in  the  hierarchy  to  capture  the  importance  the  decision-maker  places  on  a  particular 
objective.  The  weights  are  normalized  and  the  resulting  weighted  objective  hierarchy 
eventually  serves  as  the  evaluation  structure  for  each  solution  alternative  generated  in  the 
problem. 

The  trade  studies  step  is  a  new  and  innovative  step.  This  step  evolved  out  of  the 
SMAD  process.  The  purpose  of  the  trade  studies  step  is  to  make  broad  design  decisions 
that  can  be  directly  linked  to  the  study’s  goals  and  objectives.  The  emphasis  is  on 
decisions  which  can  be  made  without  having  detailed  descriptions  of  the  alternatives. 
Trade  studies  serve  as  an  efficient  and  effective  means  to  narrow  the  study’s  scope  and 
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provide  clearer  focus  early  in  the  design  process.  The  step  is  efficient  because  a 
manageable  study  focus  can  be  reached  without  the  need  for  extra  iterations  of  the 
process.  The  step  is  effective  because  it  reduces  the  number  of  possible  design 
alternatives  that  would  have  to  be  evaluated  to  determine  a  solution  to  the  study. 

The  trade  studies  occur  on  two  levels:  the  system  level  and  the  subsystem  level. 
Trades  performed  on  the  system  level  have  broader  effects  on  the  design  of  a  satellite  bus. 
These  system  level  trades  add  definition  to  the  external  environment  by  providing 
constraints  on  the  system’s  boundaries.  System  level  trade  decisions  also  impact  the 
trades  performed  on  the  subsystem  level. 

A  satellite  bus  is  a  system  comprised  of  smaller  subsystems.  Each  subsystem  can 
be  designed  in  a  variety  of  configurations  using  different  qualities  and  types  of 
components.  Some  choices  can  be  made  independent  of  choices  in  other  subsystems.  A 
subsystem  design  decision  that  is  traceable  to  the  study’s  goals  and  objectives  increases 
the  possibility  that  system  design  alternatives  will  meet  the  goals  of  the  study.  Defining  a 
subsystem  configuration  or  specifying  a  particular  quality  or  type  of  component  reduces 
the  number  of  iterations  a  designer  may  have  to  perform  to  create  a  viable  design 
alternative.  An  additional  benefit  of  including  a  trade  studies  step  early  in  the  process  is 
that  it  forces  team  members  to  focus  efforts  on  gaining  insight  into  subsystem  design  while 
simultaneously  refining  the  problem. 

Although  the  trade  studies  step  evolved  from  SMAD,  it  differs  fi'om  the  SMAD 
process  in  two  ways.  System  level  trades  in  SMAD  occur  late  in  the  process  (the 
“evaluate  the  mission”  step).  This  results  in  the  study’s  focus  and  system  boundaries  not 
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being  fiilly  defined  until  late  in  the  process.  Subsequently,  time  is  wasted  early  in  the 
process  by  identifying  the  principal  cost  and  performance  drivers  for  each  mission  concept 
and  mission  architectures  alternative  before  the  system’s  boundaries  are  defined. 

Secondly,  SMAD  does  not  specifically  mention  that  subsystem  level  trades  would  occur  in 
the  process.  It  can  be  inferred  that  the  subsystem  level  trades  would  occur  after  the 
baseline  concept  is  determined. 

The  next  step  in  the  approach  is  modeling.  Modeling  is  the  development  of  a 
descriptive  or  predictive  model  representing  a  set  of  activities  or  the  entire  system  in  order 
to  allow  analysis  of  alternative  configurations  of  the  system  (Mosard,  1982:86).  The 
modeling  step  precedes  the  system  synthesis  step,  unlike  Hall’s  traditional  approach.  This 
reordering  of  process  steps  is  because  the  creation  and  development  of  satellite  bus  design 
alternatives  is  tedious  and  complex.  Satellite  design  is  an  art  because  many  satellite 
components  have  to  be  strategically  placed  within  the  confines  of  a  satellite  structure  to 
meet  stringent  heat  dissipation,  thermal  shielding,  center  of  mass,  volume,  mass,  and  size 
constraints.  Modeling  provides  a  tool  that  permits  the  three-dimensional  visualization  of 
the  placement  and  performance  of  components.  Components  can  be  placed,  moved,  and 
resized  quite  easily  using  a  model  when  compared  to  physically  connecting,  disconnecting, 
or  replacing  components  on  an  actual  satellite.  Time  and  cost  savings  can  be  easily 
realized  through  the  use  of  a  model,  especially  if  design  requirements  or  assumptions 
change. 

In  addition,  the  model  builder  can  take  advantage  of  the  decisions  that  have 
already  been  accomplished  during  the  process.  Desired  subsystem  configurations  and 
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component  selection  from  the  trade  studies  step  can  be  easily  loaded  into  the  model  before 
alternatives  are  created.  If  component  selection  changes,  the  new  information  can  be 
easily  loaded  into  the  model.  Modeling  must  also  be  able  to  quantify  the  performance 
characteristics  of  each  design  alternative.  Different  subsystem  characteristics  can  be 
emulated  using  mathematical  models  that  can  be  programmed  into  the  tool.  The  team’s 
modeling  section  currently  uses  the  first  order  estimates  and  relationships  that  are  found  in 
the  SMAD  process.  Refinements  to  these  relationships  can  be  loaded  into  the  model  as 
the  design  develops.  As  a  minimum,  the  quantified  performance  values  must  be  those 
values  necessary  for  input  into  the  value  system’s  measures  of  effectiveness. 

The  model  must  allow  analysis  of  alternative  configurations  of  the  system.  The 
evaluation  structure  developed  in  the  value  system  design  is  incorporated  into  this  stage  of 
the  process.  This  puts  an  evaluation  structure  in  place  before  any  design  alternatives  are 
generated.  With  effective  use  of  the  modeling  tool,  it  is  possible  to  create  new  designs 
and  perform  evaluation  on  those  designs  in  a  timely  fashion. 

The  system  synthesis  step  is  similar  to  most  systematic  approach  steps  for  creating 
alternatives.  Accordingly,  alternatives  can  be  existing  designs,  modifications  to  existing 
designs,  prepackaged  designs,  or  entirely  new  designs  (Pohl,  1995).  The  difference 
between  the  system  synthesis  step  and  traditional  steps  is  its  placement  after  the  modeling 
step,  for  the  reasons  discussed  above. 

The  systems  analysis  step  follows  system  synthesis.  The  purpose  of  systems 
analysis  is  to  score  each  of  the  design  alternatives  against  the  problem’s  evaluation 
structure.  The  problem  has  been  defined  and  the  weighted  objective  hierarchy  is  in  place. 
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Each  alternative’s  input  to  the  objective  hierarchy’s  measures  of  effectiveness  is  evaluated 
and  each  solution  alternative  receives  a  score  commensurate  with  its  performance  to  the 
competing  objectives. 

Decision-making  is  a  step  that  permits  the  team  to  perform  sensitivity  analysis  on 
the  design  alternatives.  Sensitivity  analysis  is  performed  by  varying  one  variable  at  a  time. 
This  variable  is  usually  a  weight  associated  with  an  objective  in  the  objective  hierarchy. 
The  results  of  the  sensitivity  analysis  provide  insight  as  to  how  an  alternative  will  perform 
given  different  preferences  of  the  decision-maker.  Including  the  sensitivity  analysis  results 
allows  the  decision-maker  to  make  a  subjective  decision  as  to  which  design  alternative  will 
meet  the  goals  of  the  study. 

Implementation  is  the  final  step  of  the  systematic  approach.  The  purpose  of  this 
step  is  to  develop  plans  for  fielding  the  selected  alternative.  The  plan  is  presented  to  the 
decision-maker  and  reflects  the  team’s  view  on  how  the  alternative  can  be  best  put  to  use 
in  the  operational  setting.  It  provides  recommendations  for  improvements  to  the  selected 
alternative  and  to  the  associated  elements  that  affect  the  alternative.  The  implementation 
step  also  addresses  the  possible  architectures  in  which  the  alternative  can  be  deployed  and 
it  covers  the  organizational  structure  necessary  to  support  that  architecture. 

The  approach  described  above  is  an  innovative  approach  to  satellite  bus  design.  It 
provides  a  logical  sequence  which  deliberately  allows  the  design  to  evolve  fi'om  one  stage 
to  another  while  documenting  the  decisions  and  assumptions  made  along  the  way.  The 
method  permits  continual  improvements  to  the  design  as  the  design  matures.  This 
approach  provides  a  method  for  determining  if  a  design  alternative  is  the  best  design 
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possible  by  incorporating  design  decisions  made  throughout  the  process.  The  systematic 
approach  used  in  this  design  study  provides  a  holistic  view  of  the  problem  and  allows  the 
team  to  capture  all  important  aspects  affecting  the  design.  This  iterative,  systematic 
approach  ensures  that  these  aspects  are  correctly  integrated  throughout  the  design 
process. 
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3.  Team  Organization 


This  combined  approach  permitted  the  team  to  be  easily  divided  into  major  areas 
of  responsibility  within  a  matrix  organization.  The  team  concentrated  on  three  areas;  the 
major  steps  of  the  combined  Hall/SMAD  systematic  approach,  particular  satelhte 
subsystems,  and  specific  areas  of  research.  Each  team  member’s  responsibility  included 
taking  the  lead  in  charting  the  group’s  direction  for  the  steps  of  the  Hall/SMAD  (reference 
Table  3-1)  while  maintaining  a  focus  on  the  team’s  limited  time,  resources,  and  budget. 
Decisions  made  in  one  area  of  the  design  or  a  step  in  the  process  had  to  be  properly 
documented  and  presented  to  the  group  to  prevent  conflicts  between  satellite  subsystems 
and  maintain  the  direction  of  the  project.  Team  members  also  provided  the  group  with  the 
information  necessary  to  understand  each  satellite  subsystem  and  to  realize  the  influence 
and  impact  each  subsystem  had  on  the  other.  The  subsystem  assignments  are  listed  in 
Table  3-2.  Each  member  also  made  contacts  with  aerospace  companies  or  organizations 
that  had  been  involved  with  the  development  of  satellites  within  the  project’s  weight  class 
(see  Table  3-3).  Extremely  valuable  information  was  gained  by  examining  the  successes 
and  failures  of  other  organizations.  The  following  three  tables  depict  the  structure  of  the 
team’s  matrix  organization. 
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Table  3-1:  System  Steps  Responsibility  Matrix 


Steps  Of  Hall/SMAD  Approach 

Problem  Definition 

From/Krueger 

Value  System  Design 

Cokuysal 

Trade  Studies 

All 

Modeling/Analysis 

Cameal/ Ashby 

System  Synthesis 

Buck 

Systems  Analysis 

Cameal/ Ashby 

Decision  Making 

Donmez 

Implementation 

Donmez 

NOTE;  Robinson  served  as  a  “floater”  throughout  the  Hall/SMAD  approach. 


Table  3-2:  Subsystem  Expertise  Responsibility  Matrix 


Subsystem  Area  ' 

Member(s)  Responsible 

Stmctures/Mechanisms 

and  Thermal  Control 

Ashby 

Electrical  Power  Generation  and 

Distribution 

Krueger 

Attitude  Determination  and  Control 

Robinson 

Propulsion 

Cokuysal 

Telemetry,  Tracking,  and 

Commanding/Data  Handling 

Cameal/From 

Mission  Modules 

Buck 

Launch  Systems/Command,  Control  and 
Communications/Operations  Concepts 

Donmez 
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Table  3-3:  Similar  Projects  Research  Responsibility 


Research  Area 

Spectrum  Astro/MSTI 

Cokuysal 

TRW  and  CTA/STEP 

Ashby 

Lockheed-Martin/Iridium 

Cameal 

Orbital  Sciences  Corporation/Pegasus 

Donmez 

AeroAstro/HETE 

From 

Ball  Aerospace 

Buck 

Naval  Research  Laboratory\Clementine 

Robinson 

Phillips  Laboratory/MightySat 

Krueger 
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4.  Introduction 


Phase  I  represents  the  design  team’s  initial  efforts  at  applying  a  systematic 
approach  to  the  preliminary  design  of  a  generic  satellite  bus  for  small  tactical  satellite 
applications.  This  phase  is  included  to  document  the  design  team’s  progression  from  the 
start  of  the  project  to  the  end.  An  important  note  is  that  many  changes  were  made  at  the 
end  of  this  phase  that  resulted  in  the  creation  of  a  new  systematic  approach  that  was 
applied  in  the  subsequent  phase  of  the  study. 

The  team  originally  tried  to  apply  Hall’s  seven  step  process  to  the  study  while 
attempting  to  incorporate  the  methodologies  described  in  the  Space  Mission  Analysis  and 
Design  text.  The  flow  of  this  section  follows  the  traditional  steps  included  in  Hall’s 
process.  This  was  an  important  phase  for  the  team  because  it  served  as  an  introduction  to 
the  problem  and  to  methods  used  to  solve  problems.  Each  team  member  gained 
experience  through  learning  how  to  apply  the  theories  and  methods  developed  in  the 
classroom.  Perhaps  the  greatest  experience,  and  benefit  gained  through  this  process,  was 
the  fact  that  the  team  was  trying  to  solve  an  actual  United  States  Air  Force  problem. 

The  intent  of  this  iteration  was  to  estabhsh  the  nature  of  the  problem  and  its 
solution  space.  Upon  fleshing  out  the  objectives  of  the  project,  broadly  defined  alternative 
architectures  were  generated  which  could  satisfy  these  objectives.  These  alternatives  were 
subjected  to  a  qualitative  comparison  with  each  other  in  terms  of  how  well  they  met  each 
objective.  By  applying  a  systematic  approach  and  performing  the  required  steps  of  the 
process,  each  team  member  gained  insight  into  the  complexities  and  intricacies  involved  in 
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the  design  of  a  satellite  bus.  The  results  of  this  phase  served  as  a  starting  point  for  the 
second  iteration  of  the  overall  systematic  approach. 

4.1  Motivation 

Imagine  the  following  scenario  in  the  early  21st  Century.  The  United  States  is  a 
major  global  power  and  multi-regional  conflicts  continue  to  be  the  norm.  Although 
massive  Department  of  Defense  funding  reductions  have  left  the  military  with  minimal 
resources,  the  United  States  still  serves  as  the  United  Nation’s  primary  police  force.  The 
key  to  maintaining  stability  in  volatile  regions,  given  reduced  resources,  is  to  effectively 
employ  Information  Warfare  in  tactical  situations.  Through  the  use  of  rapidly  deployable 
standardized  satellite  buses,  payloads  can  be  launched  to  provide  the  situational  awareness 
necessary  to  effectively  employ  Information  Warfare. 

Once  a  remote  sensing  package  or  other  type  payload  is  launched,  a  theater 
commander  will  have  access  to  the  satellite  information  through  the  use  of  an  in-theater 
satelhte  command  and  control/data  processing  vehicle.  The  payload  data  can  be 
downlinked  in  near  real  time  to  support  the  theater  commander’s  planning  efforts  or  to 
make  an  assessment  of  actions  taken.  Paramount  to  maintaining  its  ability  to  be  a  global 
stabilizing  force,  the  United  States  needs  to  design  and  employ  standardized  satellite  buses 
to  effectively  apply  Information  Warfare.  This  scenario  provides  a  background  for  which 
the  satellite  bus  will  have  to  be  designed. 

The  use  of  space  assets  is  becoming  increasingly  essential  to  ensure  victory  on  the 
battlefield.  United  States  space  forces  must  be  responsive  and  flexible  in  order  to  support 
the  warfighter’s  short-notice  requirements.  Typically,  each  new  mission  drives  the  design 
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of  a  new  satellite  from  scratch.  This  results  in  an  untimely  response  and  an  expensive 
program.  Time  delays  and  increased  cost  are  experienced  in  the  areas  of  satellite 
development,  assembly,  and  launch.  This  process  leads  to  unique  integration  requirements 
for  launch. 

A  significant  improvement  in  cost  and  responsiveness  will  be  achieved  if  a  given 
class  of  mission  payloads  are  placed  on  a  generic  standardized  satellite  bus,  pre-configured 
to  mate  with  a  launch  vehicle.  The  current  launch  vehicles  most  suitable  for  tactical 
applications  are  the  Pegasus  and  the  Lockheed  Martin  Launch  Vehicle.  This  satellite  bus 
is  envisioned  to  be  the  backbone  of  a  new  generation  of  rapidly  deployed,  tactically 
oriented  satellites  that  will  support  the  LFnited  States  information  needs  into  the  next 
century. 

4.2  Background 

The  project  is  sponsored  by  the  Lfnited  States  Air  Force’s  Philhps  Laboratory. 
Similar  design  studies  have  been  completed  by  various  companies  and  labs,  but  to  date 
success  has  been  limited.  Phillips  Laboratory  is  seeking  a  “clean-sheet”  approach  to  the 
design  of  a  cost-effective  satellite  bus.  Several  design  characteristics  have  been  suggested 
and  wiU  be  considered  throughout  the  project.  The  sponsor  is  seeking  a  design  that  is 
modular,  flexible,  robust,  and  operable;  as  defined  below.  These  characteristics  have  been 
treated  as  guidance  in  developing  objectives  and  alternative  mission  architectures  and  are 
not  treated  as  hard  requirements. 


21 


•  Modular  -  This  concept  envisions  the  satellite  bus  as  a  large  motherboard  where 
components  and  sensors  can  be  “plugged-in”  like  personal  computer  expansion  cards 
to  meet  specific  system  needs. 

•  Flexible  -  Along  with  modularity,  the  bus  might  be  designed  such  that  additional 
capabilities  such  as  added  memory  storage  can  be  inserted  or  removed  as  mission 
requirements  dictate. 

•  Robust  -  Low  cost  and  ease  of  manufacturing  take  precedence  over  technological 
optimization.  Commercial  Off  the  Shelf  (COTS)  technology  and  hardware  should  be 
used  wherever  possible. 

•  Operable  -  This  satellite  system  is  intended  for  use  by  military  personnel.  Ideally,  the 
bus  should  be  designed  such  that  final  modular  assembly,  system  test,  and 
component/sensor  removal  and  replacement  activities  can  be  accomplished  by  an 
Airman  with  high  school  education  and  technical  school  training. 

The  first  step  of  the  systematic  approach  is  to  define  the  problem.  The  next 
section  provides  information  necessary  to  understand  the  scope  of  the  team’s  approach 
and  to  solidify  what  the  team  hopes  to  accomplish  in  this  project. 
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5.  Problem  Definition 


5.1  Introduction 

Problem  definition  was  the  first  step  of  the  systematic  approached.  The  purpose  of 
the  problem  definition  step  was  to  evaluate  the  proposed  problem  and  establish  a  succinct 
problem  statement.  Defining  the  problem  required  careful  examination  of  the  sponsor’s 
tasking  statement  and  the  factors  influencing  the  proposed  problem.  Identification  of  the 
system’s  boundary,  needs,  alterables,  constraints,  and  actors  were  important  to 
understanding  the  scope  of  the  problem. 

The  system’s  boundary  defined  those  elements  of  the  problem,  and  its  potential 
solution  space,  that  could  or  could  not  be  controlled  or  manipulated  by  the  design  team 
(Athey,  1992;  13).  Through  careful  examination  and  identification  of  the  problem’s 
boundary,  the  design  team  determined  the  factors  that  influence  and  affected  the  problem. 

Needs  were  the  driving  factors  behind  the  existence  of  the  problem.  Needs  were 
referred  to  as  requirements.  Without  the  needs,  there  would  have  been  no  problem.  By 
identifying  the  needs  of  the  chief  decision  maker  (CDM),  the  team  understood  why  the 
problem  existed,  what  the  problem  was,  and  what  some  of  the  possible  solutions  to  the 
problem  were.  Needs  also  served  as  a  means  for  measuring  the  success  of  potential 
solutions. 

Alterables  were  those  factors  the  CDM  had  control  over.  Identifying  those  factors 
provided  the  team  with  a  method  of  opening  the  potential  solution  space  to  the  problem. 
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Constraints,  on  the  other  hand,  were  factors  that  the  CDM  and  design  team  had  no  control 
over.  These  factors  limited  the  number  of  potential  solutions  to  the  problem. 

Actors  were  the  people  who  had  an  influence  on  the  problem  and  the  possible 
alternatives.  The  most  influential  actor  was  the  chief  decision  maker.  Capturing  and 
incorporating  the  decision  maker’s  needs,  values,  and  constraints  was  paramount  to 
producing  the  best  solution  possible.  The  decision  maker  provided  information  necessary 
to  determine  the  framework  by  which  all  possible  alternatives  were  measured. 

Problem  definition  was  iterative  in  nature  and  the  resulting  problem  statement  was 
subject  to  change  with  future  iterations.  This  section  of  the  report  provides  the  design 
team’s  “first  cut”  at  the  identification  of  the  system’s  boundaries,  needs  (requirements), 
alterables,  constraints,  and  actors. 

5.2  Problem  Statement 

The  team’s  first  definition  of  the  sponsor’s  problem  was: 

Design  a  rapidly  deployable,  tactically  oriented,  modular  satellite  bus  to  enhance 
theater  operations.  This  satellite  bus  is  to  support  missions  in  the  Pegasus  and  Lockheed- 
Martin  Launch  Vehicle  (LMLV)  weight  class. 

5.3  Concept  Map 

A  concept  map  was  employed  to  help  define  the  problem.  The  concept  map 
provided  a  graphic  representation  of  the  design  team’s  interpretation  of  the  problem. 
Concept  mapping  is  based  on  the  premise  that  all  knowledge  can  be  represented  by 
relationships  between  more  fundamental  concepts  (Kramer, 1990:652-654).  The  concept 
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map  consists  of  two  primitives;  concepts  and  linkages.  As  an  example,  refer  to  Figure  5- 
1 .  The  satellite  bus  is  the  central  concept.  The  motherboard  architecture  is  another 
concept.  The  device  which  connects  the  two  is  the  linkage.  The  linkage  in  this  case  is 
“has  a”.  This  method  ties  the  two  concepts  together  into  a  meaningful  structure. 

The  team  developed  the  concept  map  in  Figure  5-1  by  carefully  evaluating  the 
concepts  and  linkages  suggested  through  the  chief  decision  maker’s  tasking  statement. 
This  graphic  represented  the  design  team’s  interpretation  of  the  decision  maker’s  problem. 


The  use  of  the  concept  map  provided  many  benefits.  It  helped  the  team 


understand  how  various  factors  affected  the  problem.  The  team  immediately  realized  that 
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the  problem  was  highly  complex.  The  concept  map  generated  many  questions  the  team 
needed  answered  before  a  concentrated  approach  to  the  solution  could  be  given.  The 
team  began  to  question  how  the  operations  concept  affected  a  satellite  design.  How 
would  integration  and  launch  processing  occur?  Was  launch  vehicle  selection  an  area  to 
be  explored?  Another  question  centered  on  what  type  of  components  were  “off-the-shelf’ 
and  what  reliability  did  they  have.  The  team  also  wanted  to  know  what  effect  orbit 
selection  might  have  on  vehicle  life  time. 

The  concept  map  helped  the  team  identify  issues  that  needed  to  be  considered 
when  examining  candidate  solutions.  The  team  began  to  question  how  much  modularity  is 
needed  in  a  satellite  bus  design  and  whether  modularity  is  necessarily  good.  Other 
questions  focused  on  how  much  autonomy  a  satellite  bus  needs  and  what  reliability  is 
required  for  a  one  year  life  time. 

The  use  of  the  concept  map  was  only  a  starting  point.  The  team  realized  that 
much  research  was  needed  to  fully  understand  the  problem.  Questions  prompted  through 
the  use  of  the  concept  map  were  instrumental  in  identifying  areas  where  research  needed 
to  be  performed.  These  areas  included  researching  similar  projects,  satelhte  subsystems, 
launch  vehicles,  satellite  design  concepts,  command,  communication  and  control 
architectures,  orbital  mechanics,  and  potential  mission  modules.  The  concept  map  offered 
yet  another  benefit.  This  representation  of  the  problem  provided  a  potential  mechanism 
for  the  team  and  the  decision  maker  to  fully  discuss  what  the  problem  was  and  what  it  was 
not.  The  definition  of  the  problem  was  further  enhanced  by  establishing  system 
boundaries. 


26 


5.4  System  Boundary 


The  system  boundary  defined  those  elements  of  the  problem  and  its  potential 
solution  space  that  could  be  manipulated  by  the  design  team.  Anything  outside  of  the 
boundary  was  considered  outside  the  team’s  scope.  By  determining  the  items  that  resided 
inside  the  system  boundaries,  the  team  was  able  to  focus  the  problem  into  a  more 
manageable  size. 

As  a  first  attempt  at  scoping  the  problem,  it  was  decided  that  the  satellite  bus 
subsystems  and  interfaces,  as  well  as  mission  module  interfaces,  were  within  the  system’s 
boundary.  Operational  concepts  directly  related  to  the  use  of  the  bus  were  also  within  the 
boundary.  These  concepts  included  on-orbit  command  and  control,  storage  and 
maintenance,  mission  module  and  launch  integration,  and  sensor  data  processing.  Items 
that  were  not  considered  inside  the  system’s  boundary  included  the  development  of 
specific  mission  modules,  launch  vehicles,  and  command  and  control  facilities.  It  was  also 
determined  that  the  team  would  not  concentrate  on  innovative  or  new  state-of-the-art 
technologies. 

5.5  Needs 

Understanding  the  chief  decision  maker’s  needs  were  an  integral  part  of  defining 
the  problem.  Using  the  sponsor’s  tasking  statement  as  a  guide,  the  team  tried  to  capture 
the  CDM’s  needs  and  categorized  these  needs  into  four  functional  areas;  performance, 
responsiveness,  operational,  and  development.  The  following  provides  a  list  of  the 
sponsor’s  needs  and  shows  how  the  needs  were  categorized. 
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•  Peiformance 


-  Pegasus/LMLV  weight  class 

-  Modular,  interchangeable  components 

-  Insertion  or  removal  of  capability  as  needed 

-  Support  various  sensors  (i.e.,  electro-optical,  IR,  laser,  SAR) 

- 1  meter  Electro-Optical  (EO)  resolution  for  a  5-10  minute  imagery  pass 

- 1  meter  Synthetic  Aperture  Radar  (SAR)  resolution,  10  kilometer  by  10  kilometer 

imaging 

-  Support  on-board  storage  of  up  to  100  SAR  images 

-  Support  minimal  on-board  processing  and  data  compression  algorithms 

-  Near  real-time  transmission  of  1  m  resolution  SAR  data 

-  Encryption  of  data 


•  Responsiveness 

-  Tactically  oriented  (had  to  support  tactical  mission  modules) 

-  Rapidly  deployable 

•  Operational 

-  orbit  equal  to  or  greater  than  300  kilometers 

-  up  to  12  month  mean  mission  duration 

-  Command  uplink/telemetry  downlink  compatible  with  the  Air  Force  Satellite  Control 
Network 

•  Development 

-  Ease  of  manufacturing 

-  Off-the-shelf  technology 

-  Avoid  use  of  Class-S  parts  where  possible 

-  Avoid  extensive  redundancy 

These  lists  helped  identify  what  the  sponsor  was  trying  to  accomplish.  The  team 
examined  these  needs  and  tried  to  determine  if  any  of  the  needs  conflicted  Avith  each 
other  or  could  not  be  met.  The  major  concern  was  whether  a  satellite  bus  could  be 
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designed  to  support  the  specific  number  and  types  of  mission  modules  the  sponsor 
required.  The  team  concluded  that  more  information  was  needed  before  a  decision 
could  be  made  to  eliminate  any  of  the  needs  fi’om  the  scope  of  the  problem.  For  this 
iteration,  the  team  would  attempt  to  meet  all  the  needs  of  the  sponsor. 

5.6  Alterables  and  Constraints 

Alterables  were  those  elements  of  the  system  and  its  environment  that  could  be 
controlled  by  the  chief  decision  maker.  The  constraints  were  those  items  which  could  not 
be  changed  by  the  decision  maker.  The  team  had  to  manipulate  the  alterables  to  achieve  a 
solution,  provided  the  constraints  were  satisfied.  For  this  iteration  of  the  project,  it  was 
determined  that  every  aspect  of  the  satellite  bus  was  alterable.  This  offered  a  great  deal  of 
flexibility  in  the  design  of  bus  subsystems  and  payload  interfaces.  For  the  first  iteration, 
the  satellite  orbit  would  also  be  left  as  a  variable.  The  satellite  could  be  launched  into  a 
range  of  altitudes  within  Low  Earth  Orbit  (LEO)  by  an  appropriate  small  launch  vehicle. 
Additionally,  a  variety  of  operational  concepts  were  considered.  These  concepts  included 
areas  such  as  bus  storage  and  processing,  payload  integration,  launch  integration, 
command  and  control,  and  data  processing  and  distribution. 
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Table  5-4  shows  the  type  of  questions  that  were  considered  when  the  alterables  were 
examined  (Wertz  and  Larson,  1992:21). 
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Table  5-4:  Elements  of  the  Mission  Concept  of  Operations 


Data  Delivery 

How  is  the  mission  data  processed  and  delivered  to  the  end-user? 
How  much  processing  is  done  on-board? 

Tasking, 

Schedule,  and 

Control 

How  autonomous  is  the  system? 

What  automatic  housekeeping  functions  will  be  provided? 

Fixed  or  mobile  (or  both)  command  and  control? 

Communications 

Architecture 

How  is  sensor  data  returned  to  Earth? 

Mission 

Timelines 

When  will  first  bus  be  integrated  and  launched? 

Time  from  placement  of  order  to  launch?  (integration,  assembly, 
test,  launch  processing) 

Answers  to  these  questions  were  left  to  the  team  members  who  were  performing 
research  in  the  appropriate  areas. 

5.7  Actors 

The  actors  were  all  the  people  and  agencies  who  were  involved  with  some  aspect 
of  the  system  or  project.  It  was  important  to  understand  and  consider  the  impact  the 
system  has  on  all  actors.  The  principle  actor  for  any  project  is  the  chief  decision  maker 
(CDM).  The  CDM  generates  the  requirements  and  objectives  for  the  system,  and  is  the 
approving  and  implementing  authority  for  the  solution.  The  CDM  for  this  project  was 
LtCol  James  Rooney  of  Phillips  Laboratory,  Kirtland  Air  Force  Base.  The  design  team 
was  comprised  of  the  engineers  and  analysts  who  will  work  together  to  develop  the 
system.  This  project’s  design  team  consisted  of  space  operations  and  systems  engineering 
masters  candidates  at  the  Air  Force  Institute  of  Technology  (AFIT).  The  team  was 
advised  by  members  of  AFIT’s  Department  of  Aeronautics/ Astronautics. 
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The  eventual  user  of  bus  design  was  also  an  actor  in  this  design  study.  This  was 
the  warfighter  who  depended  on  tactical  space  assets  to  wage  effective  information 
warfare.  In  order  for  the  warfighter  to  receive  his  information,  the  project’s  satellites 
would  be  commanded  and  controlled  by  Air  Force  space  operators.  Air  Force  launch 
personnel  would  integrate  the  satellites  to  launch  vehicles  and  launch  them  into  low  earth 
orbits.  Prior  to  launch,  mission  modules  would  be  integrated  with  their  satellite  busses  by 
qualified  personnel.  Prior  to  being  required  for  missions,  ready-to-integrate  busses  would 
be  stored  and  maintained.  All  persoimel  required  to  complete  these  activities  were 
important  actors  in  the  development  of  this  system,  and  their  needs  were  considered. 
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6.  Value  System  Design 


6.1  Overview 

A  systems  engineering  approach  to  the  development  of  a  system  considers  the 
values  and  objectives  of  the  chief  decision  maker  (CDM),  The  requirements  and  values 
expressed  by  the  CDM  must  be  expressed  as  an  organized  set  of  system  objectives.  This 
set  of  objectives  should  drive  all  design  efforts,  and  it  must  serve  as  the  standard  by  which 
alternative  solutions  are  evaluated.  Often,  the  established  objectives  are  in  conflict;  that  is, 
positive  performance  for  one  objective  may  imply  negative  performance  for  another.  An 
example  of  this  is  the  use  of  cutting-edge  technology,  which  may  deliver  high  performance 
while  admitting  higher  cost  and  technological  risk.  The  objectives  must  be  organized  in 
such  a  way  that  the  engineer  may  judge  alternative  solutions  against  all  the  objectives,  and 
perform  trade-ofif  analyses  where  necessary. 

Value  system  design  translates  CDM  values  into  a  hierarchy  of  objectives,  where 
objectives  flow  down  fi'om  the  top  level  in  a  well-structured  manner.  Each  bottom-level 
objective  has  a  corresponding  measure  of  effectiveness  (MOE),  by  which  the  performance 
of  that  objective  is  measured.  In  addition,  each  objective  is  weighted,  in  terms  of 
importance,  relative  to  the  other  objectives  at  the  same  level.  Based  on  the  performance 
of  each  objective,  and  the  priorities  of  those  objectives,  alternative  solutions  receive  a 
utility  score,  which  can  be  compared  to  the  scores  of  other  alternatives.  In  this  way,  the 
value  system  allows  the  engineer  to  analyze  tradeoffs  between  competing  objectives. 

When  discussing  the  objectives  for  this  study,  it  is  very  important  to  remember  the 
system  boundary,  that  is,  what  is  within  the  scope  of  the  study.  Many  of  the  objectives 
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touch  on  areas  of  space  and  launch  operations.  While  it  was  not  the  intent  of  this  study  to 
analyze  these  areas  for  design  and  improvement,  the  design  of  Modsat  will  definitely 
impact  the  areas  of  space  and  launch  operations.  It  is  this  impact  that  must  be  considered. 

It  is  also  important  to  consider  the  timefi’ame  within  which  the  elements  of  this 
study  are  relevant.  For  instance,  some  of  the  objectives  apply  to  the  development  of  the 
bus,  others  apply  to  the  assembly  and  integration  of  the  satellite,  and  still  others  apply  to 
the  operation  of  the  satellite.  The  timeframe  for  each  objective  should  be  clear  from  the 
context  of  that  objective. 

6.2  Objectives 

The  team  determined  that  the  overall  objective  of  this  study  is  to: 

‘DEVELOP  THE  BEST  STANDARDIZED  BUS  FOR  A  SMALL  TACTICAL 
SATELLITE." 

It  is  important  to  understand  what  the  words  in  this  objective  mean  in  order  to  prevent  any 
misinterpretations  between  team  members,  advisors  and  the  chief  decision  maker.  The  key 
words  are  defined  below: 

1 .  STANDARDIZED :  The  most  important  idea  of  the  study.  All  other  objectives  must 
support  this.  The  idea  is  that  the  bus  will  support  many  different  mission  types. 

2.  THE  BEST:  Implies  an  open-minded  approach  to  developing  the  best  system,  free 
from  the  bias  of  favored  technologies  and  approaches. 

3.  SMATJ/  The  satellite  must  be  compatible  with  a  light  weight  launch  vehicle,  such  as 
the  Pegasus  or  the  Lockheed  Martin  Launch  Vehicle. 
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4.  TACTICAL:  The  project  statement  emphasizes  tactical  missions  and  a  short  life. 


All  objectives  for  this  study  were  derived  to  fit  all  top  level  mission  requirements, 
as  defined  in  the  problem  definition  step.  As  with  any  project,  there  is  a  trade-off  between 
cost  and  effectiveness.  These  are  important  aspects  of  this  design  study,  and  warrant  much 
consideration.  Therefore,  these  two  conflicting  objectives  became  the  main  top-level 
objectives.  The  top-level  objectives  are  shown  in  Figure  6-1 . 


Figure  6-1:  Top-level  Objectives 
6.2.1  Minimize  Fleet  Cost 

Cost  is  the  common  value  of  worth  for  all  parts,  processes,  actions,  and  decisions. 
Without  careful  consideration  in  separating  the  elements  of  cost,  areas  of  overlap  can  lead 
to  double  counting,  which  inflates  predicted  system  cost.  It  should  be  noted  that  launch 
costs  are  beyond  the  scope  of  this  study.  As  this  standard  satellite  bus  will  be  designed 
for  multiple  applications,  the  cost  for  fleet  production  has  been  considered.  Cost 
objectives  are  shown  in  Figure  6-2. 
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Figure  6-2:  Cost  Objectives 


6.2.1. 1  Minimize  Acquisition  Cost 


Acquisition  costs  cover  all  recurring  and  non-recurring  costs  as  the  system 
progresses  from  an  idea  to  a  finished  end  item. 


Figure  6-3:  Acquisition  Cost  Objectives 

0-1.  Minimize  Development  Cost:  Includes  all  expenditures  from  problem  definition  to 
production. 

0-2.  Minimize  Manufacturing  Cost:  Cost  of  producing  the  system;  includes  qualification 
testing. 


6.2. 1.2  Minimize  Operations  Cost 


The  operations  phase  begins  with  the  satellite  as  a  finished  product,  and  includes 
integration  with  the  payload  and  launch  system.  It  also  includes  on-orbit  operational  costs 
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such  as  command  and  control,  data  processing  and  other  ground  segment  expenditures. 
Operations  cost  objectives  are  shown  in  Figure  6-4. 


Figure  6-4:  Operations  Cost  Objectives 

0-3.  Minimize  Mission  Module  Integration  Cost:  The  cost  of  mating  a  mission  module  to 
the  bus;  covers  aU  hardware  and  software  interface  and  testing  expenditures. 

0-4.  Minimize  Launch  Integration  Cost:  Covers  all  efforts  to  fit  the  mission-ready 
satellite  to  a  launch  vehicle. 

0-5.  Minimize  Inventory.  Storage  and  Supply  Cost:  The  cost  of  having  a  fleet  of  satellite 
busses  in  a  mission-capable  configuration .  Between  manufacturing  and  usage,  the  fleet 
must  be  stored,  cared  for,  and  kept  mission-ready. 

0-6.  Minimize  On-Orbit  Cost:  All  expenditures  for  orbital/system  maintenance  such  as 
command  and  control,  data  processing,  and  ground  segment  activities. 


6.2. 1.3  Minimize  Retirement  Cost 


0-7.  Minimize  Retirement  Cost:  Upon  conclusion  of  a  satellite’s  operational  life. 


environmental  and  orbital  space  considerations  deem  that  it  be  removed  from  operational 


orbit.  This  cost  must  be  considered  up  front. 
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6.2.2  Maximize  System  Effectiveness 


The  elements  which  define  system  effectiveness  have  been  chosen  as  shown  in 
Figure  6-5. 


Figure  6-5:  Effectiveness  Objective 
6.2.2. 1  Maximize  Flexibility 

The  standard  bus  must  be  flexible  for  use  with  different  missions,  payloads,  launch 
vehicles,  orbits  and  other  specifications.  Flexibility  has  been  defined  as  shown  in 
Figure  6-6. 


Figure  6-6:  Flexibility  Objectives 


0-8.  Maximize  Expandability;  The  system  must  respond  to  different  mission  requirements 


while  satisfying  the  constraints.  Elements  such  as  power,  memoiy,  and  earth  coverage 


must  be  adaptable  to  different  demands. 
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0-9.  Maximize  Deployability:  Considers  the  flexibility  of  selection  of  orbital  parameters 
for  low  earth  orbits. 

0-10.  Maximize  Weight  and  Volume  For  Mission  Module:  Optimum  mission  module 
capacity  occurs  with  minimum  bus  weight  and  volume,  since  total  satellite  weight  and 
volume  are  constrained  by  the  launch  vehicle. 

6.2.2.2  Maximize  Availability 

The  on-orbit  availability  of  the  satellite  must  be  maximized,  considering  the 
elements  shown  in  Figure  6-7. 


Figure  6-7;  Availability  Objectives 


0-11.  Maximize  Reliability:  Minimize  the  probability  of  failure  for  the  overall  system  over 
the  mission  life,  under  nominal  operating  conditions  (no  environmental  or  man-made 
threats). 

0-12.  Maximize  Survivability.  The  ability  of  the  system  to  perform  its  intended  function 
afl;er  being  exposed  to  stressing  enviromnents  created  by  an  enemy  or  hostile  agent. 

0-13.  Maximize  Hardness:  An  attribute  defining  the  spacecraft’s  ability  to  withstand 
natural  environmental  threats  and  stresses. 
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6.2.2.3  Maximize  Responsiveness 


Since  this  spacecraft  bus  is  to  be  used  for  tactical  missions,  the  time  required  to 
meet  the  warfighter’s  needs  must  be  minimized.  Responsiveness  implies  a  light  weight, 
easily  deployable,  agile  bus  that  can  meet  short-term  military  mission  requirements. 


Figure  6-8:  Responsiveness  Objectives 

0-14.  Minimize  Turn  Around  Time  To  Launch:  The  time  period  from  the  initial  mission 
demand  until  placement  in  orbit.  This  time  covers  hardware  and  software  preparation, 
mission  module  integration,  and  launch  integration. 

0-15.  Minimize  Time  For  Useful  Data:  The  time  period  from  satellite  sensor  collection  of 
raw  data  until  the  warfighter  receives  his  information  in  the  field.  Considers  queuing, 
processing,  and  distribution. 


6.2.2.4  Maximize  Capability 

0-16.  Maximize  Capability;  The  system  should  perform  so  as  to  enhance  information 
flow  into  combat  theaters.  This  topic  covers  the  performance  of  system  elements.  It  is 
not  restricted  to  satellite  specific  elements,  but  also  includes  mission  module,  user,  and 
operator  interfaces.  The  bus  should  be  designed  to  optimize  satellite/user  interfaces  such 
as  data  rates,  accessibility,  compatibility,  and  encryption,  while  satisfying  all  other 
objectives  as  well.  On-orbit  performance  factors  include  pointing  accuracy,  thermal 
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control,  satellite  autonomy,  attitude  control,  and  self-diagnostics  (Reeves,  1992:285-337). 
Simplicity  of  operations  should  be  considered,  including  mission  planning,  compatibility  of 
data  links,  and  telemetry  analysis. 

Note:  This  objective  was  created  as  a  the  head  of  several  potential  performance 
subobjectives,  to  be  identified  in  a  later  iteration  of  the  study.  However,  in  the  first  phase 
of  the  study,  it  was  decided  that  the  first  order  solutions  would  not  have  enough  detail  to 
warrant  further  definition  of  this  objective. 


6.3  Measures  Of  Effectiveness 

Each  of  the  16  bottom-level  sub-objectives  requires  a  measure  of  effectiveness. 
Objective  MOEs  based  on  natural  performance  scales  were  not  feasible  for  this  first,  quick 
iteration  through  the  design  process.  Since  the  purpose  of  the  first  iteration  is  to  get  a 
rough  idea  of  what  possible  alternatives  are  feasible  for  this  design,  the  team  decided  to 
use  subjective  judgments  to  determine  the  performance  of  each  alternative  with  regard  to 
the  objectives. 

Moreover,  rather  than  attempt  to  find  fixed  reference  points  for  the  performance  of 
each  objective,  the  team  decided  to  judge  the  relative  performance  of  each  alternative  with 
respect  to  the  other  alternatives.  For  each  bottom-level  objective,  team  members 
performed  pairwise  comparisons  of  the  alternatives,  in  much  the  same  manner  by  which 
the  objective  weights  were  determined  (see  section  6.4).  Thus,  performance  scores  were 
determined  for  each  alternative,  objective  by  objective. 


41 


6.4  Priority  Weighting  of  The  Objectives 


As  mentioned  in  section  6. 1,  the  objectives  must  be  given  relative  importance  in 
the  form  of  weights.  Only  the  objectives  on  the  same  level  of  the  hierarchy  should  be 
compared.  These  objective  weights  must  reflect  the  priorities  and  values  of  the  decision 
maker.  Thus,  participation  from  the  CDM  is  critical  in  completing  the  objective  structure. 
This  was  accomplished  through  the  use  of  a  preference  chart  survey,  such  as  that  shown  in 
Appendix  A  for  phase  two  of  this  study.  A  preference  chart  survey  requires  the 
respondent  to  evaluate  the  relative  importance  of  items  in  a  series  of  pairwise  comparisons 
(Athey,  1982).  Surveys  were  distributed  to  the  CDM,  faculty  advisors,  team  members,  and 
other  subject  matter  experts. 

In  the  survey,  a  participant  has  five  possible  comparison  ratings.  When  objective 
A  is  compared  to  objective  B,  objective  A  could  be  ‘much  more  important  than’,  ‘more 
important  than’,  ‘the  same  as’,  ‘less  important  than’  or  ‘much  less  important’  than 
objective  B.  Each  rating  has  an  assigned  value:  4.0,  2.0,  1.0,  0.5,  and  0.25,  respectively. 
An  objective  is  compared  to  all  the  other  objectives  on  the  same  level  of  the  hierarchy, 
resulting  in  a  series  of  values.  A  relative  score  for  a  given  objective  is  obtained  by  taking 
the  geometric  mean  of  all  its  comparison  values  (Pohl,  1995).  Finally,  the  relative  scores 
for  each  objective  are  normalized  so  that  they  add  up  to  one  (see  section  13.6  for  a 
description  of  the  additive  utility  function  used  for  this  study).  The  resulting  value  for 
each  objective  is  the  weight  of  that  objective,  according  to  the  person  who  completed  the 
survey. 
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The  results  of  all  the  surveys  were  averaged.  Feedback  from  the  CDM  and  from 
the  faculty  advisors  was  given  double  emphasis.  The  resulting  priority  weights  are  shown 
in  Figure  6-9. 


Figure  6-9:  Phase  One  Objective  Hierarchy 
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7.  System  Synthesis 


7.1  Introduction 

The  goal  of  system  synthesis  is  to  generate  alternative  solutions  which  sufficiently 
span  the  needs  (i.e.,  meet  the  minimum  requirements)  addressed  by  the  problem  statement. 
Given  the  very  general  nature  of  the  initial  statement  of  needs,  the  iterative  design 
approach  must  start  with  high-level  designs.  Through  further  iterations,  these  high-level 
designs  should  evolve  as  necessary  into  more  detailed  designs,  slowly  but  surely 
incorporating  more  elements  at  lower  (component)  levels  of  the  system. 

7.2  Architectural  Themes 

The  first  step  of  the  System  Synthesis  is  to  provide  top-level  alternative 
architectures  which  span  the  myriad  of  lower-level,  detailed  choices  available  for  single 
components  or  elements  of  the  design.  This  approach  provides  an  introduction  and 
overview  not  only  to  the  general  (high-level)  tradeoffs  involved  with  satellite  design,  but 
also  to  the  whole  process  of  generating  alternatives  for  evaluation.  The  early 
brainstorming  sessions  of  the  system  design  study  provided  widely  varying  ideas  spanning 
all  of  the  major  elements  of  space  system  architecture.  Elements  under  consideration 
included  not  only  the  spacecraft  bus  and  the  payload,  but  also  the  command  and  control 
infrastructure,  the  launch  and  ground  segments,  etc.  (i.e.,  brainstorming  sessions  were 
exhaustive).  The  brainstorming  sessions  concluded  with  the  following  concepts;  [1]  care 
must  be  exercised  in  creating  initial  candidate  architectures  that  are  not  overly  detailed 
but  are  differentiable;  [2]  brainstorming  sessions  spanned  not  only  spacecraft  options  but 
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operational  and  employment  options,  thus  possibly  creating  multiple  combinations  too 
numerous  to  effectively  evaluate  as  detailed  designs  in  a  timely  manner;  [3]  candidate 
designs  must  concentrate  on  the  spacecraft  element,  with  options  for  other  space  system 
elements  held  as  secondary;  [4]  candidate  designs  must  be  fiilly  characterized  (at  the 
system  level  --  not  the  component  level)  to  provide  an  introduction  to  and  deeper 
understanding  of  spacecraft  design  for  those  members  of  the  study  who  are  less  familiar 
with  satellite  technology. 

The  brainstorming  data  provided  ample  ideas  for  creativity.  From  the  outset  of  the 
system  synthesis  process,  it  was  apparent  that  a  classical  “morphological”  approach  to 
candidate  design  generation  was  inappropriate  to  the  general  scope  of  the  team’s  first 
(high  level)  efforts.  Therefore,  candidate  designs  known  as  “architectural  themes” 
developed.  This  “thematic”  approach  seeks  to  span  the  range  of  different  design 
philosophies  available  within  the  scope  of  the  problem.  These  themes  do  not  necessarily 
incorporate  different  components  within  the  satellite  designs  they  represent,  but  are 
intended  as  differentiable  methods  for  building  and  employing  satellites  out  of  (possibly) 
the  same  (i.e.,  standardized)  components.  Through  this  approach  to  system  synthesis,  the 
team  can  evaluate  the  different  spacecraft  architectural  themes  for  their  general,  relative 
merits  and  reserve  not  only  component-level  considerations  for  future  system  synthesis 
and  analysis,  but  also  other  elements,  such  as  employment  or  command  and  control 
options,  for  future  implementation  recommendations. 
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7.2.1  Initial  Spacecraft  Architectures 


7.2.1. 1  “Baseline”  or  “Point”  Design 

The  “Baseline”  (“One  Size  Fits  All”  design)  provides  a  single  bus  design  capable  of 
supporting  any  of  the  required  payload  types.  The  “Baseline”  supports  one  payload  per 
flight,  and  does  not  incorporate  any  onboard  processing  of  mission  data  or  spacecraft 
autonomy.  The  “Baseline”  bus  communicates  only  through  the  AFSCN.  The  key 
philosophy  is  to  design  a  satellite  bus  to  the  most  demanding  requirements  in  each 
subsystem  (e.g.,  power,  attitude  control,  data  handling,  data  storage,  etc.)  necessary  to 
support  any  of  the  required  mission  options.  This  design  is  not  optimized  for  any  one 
particular  mission. 

7.2.1.2  “Amoebae”  Design 

The  second  spacecraft  architecture  is  aptly  named  the  “Amoebae”  design.  This 
design,  also  known  as  the  “Ultimate  Chinese  Menu,”  incorporates  a  fully  modular, 
possibly  expandable  bus  construction,  complete  with  “plug  and  play”  subsystem 
components  such  as  battery  modules,  solar  arrays,  memory  modules,  reaction  wheels,  etc. 
This  bus,  like  the  ‘Baseline”,  incorporates  no  special  processing,  autonomy,  or  command 
and  control  options,  but  it  may  support  one  or  more  payloads  if  desired.  This  design’s 
philosophy  concentrates  on  the  ability  to  tailor  and  optimize  the  vehicle  to  a  particular 
mission,  including  the  possibility  of  dual  or  multiple  payloads,  providing  maximum  design 
flexibility. 


46 


7.2.1.3  “Family”  Design 


A  possible  alternative  to  the  ’’Baseline”  design  is  one  which  spans  multiple  mission 
or  payload  needs  by  providing  two  or  more  similar  but  distinct  buses,  each  designed  and 
built  to  support  a  smaller  subset  of  the  overall  payload  types.  These  buses  incorporate  no 
modularity  and  no  onboard  processing  or  autonomy.  They  support  one  payload  or 
mission  per  flight.  Although  this  design  philosophy  is  similar  to  the  “Baseline”,  the 
‘Family”  of  satellites  will  be  different  in  capability,  size,  mass,  and  mission  applicability. 
The  family  of  architectures  essentially  forms  a  set  of  “Point”  designs. 


7.2. 1.4  “Microsat”  or  “Pocketsat”  Design 

The  “Microsat”  design  architecture  provides  satellites  individually  optimized  for 
particular  missions  (i.e.,  every  mission  or  payload  type  has  a  specific  satellite  —  no  real 
“standard  bus”).  This  design  is  not  a  standard  vehicle,  although  several  may  coincidentally 
look  and  operate  similarly.  Instead,  a  “standard”  philosophy  will  be  applied  across  all 
subsystems  incorporating  a  "seamless"  architecture  to  minimize  weight  and  volume,  yet 
maximize  effective  performance.  Microsats  emphasize  very  small  (less  than  50  kilograms, 
possibly  man-portable)  mass,  optimization  of  payload  support  requirements,  and 
miniaturization/multifunctionality  of  components.  There  will  be  no  discernible  “border” 
between  where  the  bus  ends  and  where  the  payload  begins  because  all  the  components  on 
the  satellite  will  have  been  fully  and  optimally  integrated  (for  that  particular  type). 
Development  efforts  for  minimizing  payload  mass  will  mirror  those  for  the  bus 
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subsystems.  Again,  there  will  be  no  provisions  for  autonomy,  data  processing,  or 
communication  other  than  through  the  AFSCN. 


7.2.1.5  The  "Works”  Design 

The  final  spacecraft  architecture  under  consideration  is  the  “Works”  design.  As 
the  name  implies,  the  works  spacecraft  will  include  as  much  capability  as  possible  on  one 
spacecraft  bus.  This  design  is  intentionally  as  large  as  mass  constraints  allow  and  is  also 
capable  of  supporting  several  payload  packages  on  the  same  bus.  Additionally,  the  bus 
incorporates  full  redundancy,  radiation  hardening,  and  satellite  autonomy  features. 
Extensive  onboard  mission  data  processing  is  available  before  downlinking.  The  bus  will 
have  a  useful  service  life  of  greater  than  one  year.  Since  many  mission  features  are 
supported  by  the  software  subsystem,  the  spacecraft  is  reconfigurable  after  launch  via 
database  uploads.  Also,  this  design  is  basically  a  larger,  more  complex  version  of  the 
‘'Baseline”  design,  enhancing  many  mission  capabilities  through  sophistication  and 
achieving  multiple  payload  objectives  through  sheer  horsepower. 


7.3  Evaluation  Considerations 

Though  very  general  in  nature  and  deliberately  lacking  specific  components,  the 
design  philosophies  provide  significant  differentiation  through  their  approaches  to  meeting 
mission  objectives.  These  approaches  will  drive  different  factors  inherent  in  each  design’s 
technology,  cost,  operability,  reliability,  etc.  The  primary  emphasis  in  each  case  can  be 
summarized  as  follows: 
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1 .  Baseline  Design;  support  any  mission  with  a  single  bus 

2.  Amoebae:  support  any  or  more  than  one  mission  with  a  tailorable  bus 

3.  Family:  several  buses  span  the  desired  needs 

4.  Microsat;  each  payload  is  an  optimized  satellite  in  itself,  minimizing  mass 

5.  Works:  large  satellite  supporting  several  missions  at  once 


7.3.1  Employment  Options 

In  addition  to  the  core  of  five  spacecraft  architectures,  some  initial  operational 
concepts  came  to  light.  Because  these  employment/deployment  schemes  did  not  directly 
relate  to  specific  satellite  architectures,  they  were  considered  as  implementation 
recommendations  and/or  operational  alternatives  suitable  for  fiirther  investigation. 

7.3. 1.1  “Fire  and  Forget” 

As  implied  by  the  title  for  this  employment/deployment  option,  operations 
personnel  prepare  and  launch  the  spacecraft,  which  then  operates  with  complete 
autonomy.  The  only  contact  made  with  the  vehicle  by  operations  personnel  after  launch 
will  be  for  the  collection  of  fully  processed  mission  data  downlinked  from  the  vehicle.  The 
concept  of  the  “probe”  vehicle  used  in  certain  science  fiction  stories  (probes  in  the  “Star 
Trek”  series  are  prominent)  is  a  good  analogy  for  this  option. 
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7.3.1.2  “Starnet” 


The  “Stamet”  is  a  network  of  crosslinked,  autonomous  vehicles,  creating  not  only 
a  more  robust  command  and  control/data  transmission  network  but  also  a  synergy  of  the 
variety  of  mission  data 

7.3. 1.3  “Reusable”  Satellite 

This  concept  utilizes  either  an  in  place  or  deployable  heat  shield  for  the  de-orbit 
and  recovery  of  the  spacecraft.  This  employment  scheme  allows  recovery,  refurbishment, 
reloading,  and  relaunch  of  a  satellite  after  completion  of  a  particular  mission. 
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8.  System  Modeling 


8.1  Introduction 

Discussions  up  to  this  point  have  focused  on  defining  the  problem,  establishing 
criteria  and  MOEs.  In  the  last  section  the  System  Synthesis  process  produced  various 
alternative  solutions,  which  will  be  investigated  further.  Typically,  in  System  Synthesis  the 
feasibility  of  the  alternatives  are  evaluated  by  checking  them  against  the  constraints  and 
verifying  that  they  meet  minimum  standards.  However,  because  little  is  known  of  what 
the  standard  should  be,  all  alternatives  were  passed  and  evaluated  against  one  another  for 
the  16  objectives  discussed  in  Value  System  Design.  The  scores  for  the  five  alternatives 
for  each  objective  were  then  normalized  and  these  were  then  evaluated  against  the 
remaining  upper  level  objective  criteria  to  obtain  an  overall  rating  of  that  alternative 
against  the  others. 

The  objective  was  to  model  the  alternatives  in  such  a  way  as  to  get  results  on  how 
well  they  stack  up  in  the  objective  hierarchy  as  established  in  Value  System  Design.  This 
process  causes  the  alternatives  to  have  relative  worth  based  upon  other  ideas  in  the 
solution  space.  Microsoft  Excel  was  chosen  as  a  tool  to  help  automate  the  process  of 
modeling  alternatives  in  Value  System  Design. 

8.2  Purpose 

A  tool  was  needed  to  model  the  objective  hierarchy  created  within  Value  System 
Design.  The  intent  was  to  automate  evaluation,  and  to  ensure  such  evaluation  was 
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performed  the  same  way  each  time.  The  benefits  were  consistent  performance  of  steps 
and  time  saving  once  the  model  was  created  and  checked  for  valid  output  on  calculations. 

8.3  Confidence  Level  in  Data 

Confidence  of  the  data  is  limited  primarily  due  to  four  main  factors.  First,  the  data 
collected  from  the  surveys  is  only  as  good  as  the  expertise  of  those  surveyed.  Although 
the  data  obtained  is  sufficient  for  a  first  look,  individuals  or  groups  with  more  field 
experience  will  need  to  be  contacted  in  future  surveys.  Second,  the  data  collected  for  this 
section  was  based  on  only  eight  inputs,  which  is  clearly  insufficient  for  establishing  high 
confidence  tables.  Third,  although  the  alternatives  were  compared  equally  they  will  likely 
vary  in  many  aspects.  Manufacturing  may  be  more  complex  for  one  design  than  another, 
or  logistics  for  storage  may  be  more  difficult  or  costly  for  one  design  over  another.  In 
essence,  it  is  really  difficult  to  compare  a  “Microsat”  against  “Amoebae”  without  knowing 
more  about  the  current  technology.  Lastly,  in  defining  the  alternatives  assumptions  were 
made  which  may  not  be  true  representations. 

In  any  modeling  scenario  key  assumptions  must  be  made  to  avoid  building  too 
much  complexity.  Otherwise,  the  model  becomes  unmanageable  and  outside  the  scope 
of  its  true  purpose.  Because  these  assumptions  have  tremendous  impact  in  the  outcome  of 
the  model,  it  is  important  to  discuss  them  here.  The  following  items  describe  the 
assumptions  for  each  of  the  objectives; 
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Minimize  Development  Cost: 

•  “The  Works"  is  fully  redundant  and  autonomous 

•  Amoebae  will  be  an  integration  “nightmare” 

•  Point  Design  and  Family  are  about  equal  in  development  cost 

•  Microsat  technology  is  revolutionary  and  will  require  more  money  to  develop  than  the 
other  systems. 

Minimize  Manufacturing  Cost: 

•  “The  Works”  is  an  intricate  and  sophisticated  satellite 

•  Amoebae  and  “The  Works”  will  require  advances  in  assembly  line  technology 

•  The  ‘Tamily”  versus  “The  Works”  is  similar  to  a  Yugo  versus  a  Rolls  Royce 

•  Microsat  will  be  easier  to  build  than  the  other  satellites  since  it  will  be  manufactured 
much  like  a  circuit  board  on  an  assembly  line 

Minimize  Mission  Module  Integration  Cost: 

•  “The  Works”  will  contain  multiple  payloads 

•  Amoebae  will  be  the  most  complex  satellite  to  try  to  integrate  payloads 

•  Microsat  will  be  built  with  the  assumption  payloads  will  also  be  miniaturized 
Minimize  Launch  Integration  Cost: 

•  Amoebae  is  extremely  complex,  requiring  testing  and  integration  in  phases 

•  Microsat  is  one  payload  versus  many  for  “The  Works” 


53 


Minimize  Inventory,  Storage,  and  Supply  Cost: 

•  Amoebae  will  be  more  costly  because  of  the  increased  inventory  due  to  all  parts  being 
modular,  and  parts  may  change  as  technology  changes 

•  Family  has  a  small  set  of  fixed  designs,  and  thus  has  known  items  to  maintain  on 
inventory 

•  Microsat  will  require  more  configuration  management 

•  “The  Works”  complexity  requires  more  follow-up  and  hardware/software  checkout 

Minimize  On-Orbit  Cost: 

•  Amoebae  is  more  diverse  than  the  other  satellites,  thus  requiring  more  resources  to 
maintain  it. 

•  Microsat  will  be  the  easiest  to  maintain  since  it  will  have  built  in  self  checks 

•  “The  Works”  -  will  work  as  it  was  designed  to 

Minimize  Retirement  Cost: 

•  Microsat  will  be  the  cheapest 

•  Because  of  how  much  we  put  into  “The  Works”,  it  becomes  an  investment.  Its  loss 
will  have  an  impact  on  development  and  user  community 

Maximize  Expandability: 

•  Point  Design  is  fixed  and  not  as  flexible  as  the  Amoebae  design 

•  ‘Tamily”  is  a  little  better  than  the  Point  Design 

•  Amoebae  is  the  best  because  it  is  designed  with  maximum  modularity 
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•  “The  Works”  will  be  the  most  difficult  to  reconfigure  once  built. 


Maximize  Deployability: 

•  Microsat  has  no  maneuvering  capability 

•  ‘Tamily”  and  the  Amoebae  satellites  can  by  their  design  carry  additional  fuel  if 
necessary 

•  “The  Works”  is  heavy  and  will  require  more  fiiel  to  maintain  orbit  parameters  than  the 
other  satellites 

Minimize  Weight  &  Volume  For  Mission  Module; 

•  Point  Design  is  a  larger  satellite  to  accommodate  all  the  various  payloads 

•  ‘Tamily”  and  Amoebae  are  more  tailored  to  specific  payload,  thus  minimizing  weight 
and  volume 

Maximize  Reliability: 

•  Amoebae  is  more  likely  to  break  with  the  many  and  complex  interfaces 

•  Microsat  is  newer  technology  and  may  not  be  that  reliable  in  earlier  satellites 

•  “The  Works”  is  built  on  the  premise  it  will  be  highly  reliable  and  redundant 
Maximize  Survivability: 

•  “The  Works”  is  built  for  survival  against  offensive  measures 

•  Microsat  is  smaller  and  harder  to  attack  with  lasers  or  AS  AT  weapons 

•  Amoebae  is  not  equipped  with  shielding  to  maximize  modularity 
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Maximize  Hardness: 


•  “The  Works”  is  built  to  withstand  the  harsh  space  environment 

•  Amoebae  is  less  likely  to  survive  than  the  other  satellites 

Minimize  Turn  Around  Time  To  Launch: 

•  “The  Works”  will  require  more  software/hardware  testing  than  the  typical  satellite 

•  Amoebae  is  the  worst,  requiring  extensive  phase  testing  during  integration 

•  Microsat  is  the  best  with  a  “launch-and-go”  ability 
Minimize  Time  For  Useful  Data: 

•  “The  Works”  is  slightly  better  than  the  other  satellites 

•  Remaining  satellites  are  essentially  equal  in  on-board  processing 
Maximize  Capability: 

•  “The  Works”  is  slightly  better 

•  Microsat  contains  payloads  that  can  meet  performance  requirements 

8.4  Evaluation  Tool 

To  evaluate  the  alternatives  an  Excel  workbook  was  developed  and  used.  It 
utilizes  weights  from  the  objective  hierarchy  and  accepts  inputs  from  one  or  more  surveys 
on  pairwise  comparison  of  architectural  themes.  From  these  it  calculates  geometric  means 
of  each  alternative  under  each  sub-objective  before  normalizing  the  weights.  Next,  the 
model  calculates  weights  of  alternatives  for  each  objective,  then  graphically  displays  the 
results. 
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8.4.1  Survey  Model 


The  eight  members  of  the  Systems  Engineering  Group  performed  a  pairwise 
comparison  of  all  five  alternative  architectures  for  each  and  every  bottom  level  objective  in 
the  objective  hierarchy.  By  using  pairwise  comparison  any  given  alternative  is  judged 
against  any  other  given  alternative  for  a  given  objective  through  the  following  ratings: 
much  better  than,  better  than,  equal  to,  worse  than,  or  much  worse  than.  Criteria  used 
were  as  follows; 

•  Alternative  j  much  better  than  k  receives  rating  ”+  +"  (numerical  equivalent  =  4) 

•  Alternative  j  better  than  k  receives  rating  (numerical  equivalent  =  2) 

•  Alternative  j  equal  to  k  receives  rating (numerical  equivalent  =  1) 

•  Alternative  j  worse  than  k  receives  rating (numerical  equivalent  =  0.5) 

•  Alternative  j  much  worse  than  k  receives  rating  (numerical  equivalent  =  0.25) 


57 


9.  System  Evaluation 


9.1  Introduction 

In  the  previous  section  the  Team  determined  a  ranking  of  alternatives  one  against 
another,  given  estimated  conditions.  The  CDM  wants  to  know  what  happens  if  conditions 
of  the  modeling  are  different  than  were  expected.  The  CDM  is  also  interested  in  knowing 
what  latitude  exists  if  less  than  the  optimal  solution  is  selected.  To  meet  this  requirement, 
conditions  of  the  model  need  to  be  modified  to  provide  some  flexibility  to  the  original 
solution  set.  In  the  business  world  this  process  is  called  ‘Decision  Analysis,”  the  varying 
of  original  conditions  to  see  trends.  "Decision  analysis  is  typically  an  iterative  process. 
Once  a  model  has  been  built,  sensitivity  analysis  is  performed.  Such  analysis  answers, 
'what  if  questions:  'If  we  make  a  slight  change  in  one  or  more  aspects  of  the  model,  does 
the  optimal  solution  change?"'  (Clemen,  1996:7).  System  Evaluation  uses  a  similar 
process,  where  conditions  of  a  model  or  criteria  are  changed  to  see  how  alternatives  fair 
under  different  conditions.  One  approach  is  to  vary  the  weights  assigned  in  the  overall 
objective  hierarchy.  The  Excel  workbook  model  would  then  feed  through  the  new 
weights  and  re-calculate  the  results. 

9.2  Pairwise  Comparison 

Based  on  results  of  pairwise  comparison,  the  Microsat  option  scored  with  the 
highest  weighting.  However,  the  Microsat  solution  did  not  lead  the  others  by  a  very  wide 
margin,  so  changes  in  objective  hierarchy  weighting  may  give  a  different  leading  option. 
This  result  can  be  seen  in  Figure  9-1; 
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Figure  9-1:  Overall  Comparison 

9.3  Scenarios 

To  determine  if  Microsat  was  the  overall  best  solution,  conditions  of  the  evaluation 
were  modified.  To  do  this  analysis  an  individual  part  of  the  objective  hierarchy  was 
altered  significantly  by  varying  the  weight  to  seventy-five  percent  of  its  original  value  in 
the  hierarchy.  The  other  weights  at  that  level  were  proportionately  decreased  to  maintain 
the  same  relative  weights,  while  ensuring  the  total  weights  still  added  to  one.  An  example 
is  shown  in 
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Table  9-1 .  In  this  scenario  acquisition  cost  weighting  factor  was  made  the  most 
important  consideration  for  fleet  cost. 
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Table  9-1:  Acquisition  Cost  Example  for  Generating  Scenario 


Objective  ; 

Original  Weight  in  ^ 

Objective  Hierarchy  i 

New  Relative  Weights  in 
Scenario 

Minimize  Acquisition  Cost 

0.49 

0.75 

Minimize  Operation  Cost 

0.38 

0.19 

Minimize  Retirement  Cost 

0.13 

0.06 

TOTAL 

1.00 

1.00 

The  two  primary  scenarios  were  generated  and  compared: 

1 .  Fleet  cost  is  the  driving  factor 

2.  Maximizing  effectiveness  is  the  driving  factor 

To  determine  the  impacts  of  subobjectives  on  the  solution  set,  seven  sub-scenarios  were 
generated  and  compared: 

1 .  Acquisition  cost  is  the  most  important  consideration  for  fleet  cost 

2.  Operation  cost  is  the  most  important  consideration  for  fleet  cost 

3 .  Retirement  cost  is  the  most  important  consideration  for  fleet  cost 

4.  Flexibility  is  the  most  important  consideration  for  effectiveness 

5 .  Availability  is  the  most  important  consideration  for  effectiveness 

6.  Responsiveness  is  the  most  important  consideration  for  effectiveness 

7.  Capability  is  the  most  important  consideration  for  effectiveness 

The  Excel  model  was  used  as  the  tool  to  perform  the  above  scenarios  and  generated 
results  shown  in  the  following  figures: 
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Figure  9-2:  Scenario  Results  for  Cost  as  the  Driving  Factor 
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Figure  9-3:  Scenario  Results  for  Effectiveness  as  the  Driving  Factor 
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9-4:  Scenario  Results  for  Acquisition  Cost  as  Most  Important  for  Fleet  Cost 
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Figure  9-5:  Scenario  Results  for  Operation  Cost  as  Most  Important  for  Fleet  Cost 
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Attemirtive  n  Alternative 


Overall  Weighting  of  Alternatives  for  Modular  Satellite  Bus 
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9-6:  Scenario  Results  for  Retirement  Cost  as  Most  Important  for  Fleet  Cost 
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Figure  9-7:  Scenario  Results  for  Flexibility  as  Most  Important  for  Effectiveness 
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Alternative 


Figure  9-8:  Scenario  Results  for  Availabilitv  as  Most  Important  for  Effectiveness 
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Figure  9-9:  Scenario  Results  for  Responsiveness  as  Most  Important  for  Effectiveness 
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Overall  Weighting  of  Alternatives  for  Modular  Satellite  Bus 


Figure  9-10:  Scenario  Results  for  Cavabilitv  as  Most  Important  for  Effectiveness 

Overall,  the  System  Evaluation  step  determined  the  Microsat  architecture  to  be  the 
best  solution  to  all  scenarios.  However,  the  Microsat  option  does  not  always  lead  the 
other  architectures  by  a  wide  margin,  and  further  investigation  may  reveal  another  solution 
to  be  the  best  option  overall. 


66 


10.  Decision  Making 


10.1  Introduction 

In  this  section,  the  consequences  of  the  alternatives  which  are  developed  in  system 
analyses  relative  to  the  objectives  will  be  evaluated  and  these  evaluations  will  be 
incorporated  into  the  decision  criterion  so  that  all  alternatives  can  be  compared  relative  to 
the  criterion.  This  will  enable  one  or  more  alternatives  to  be  selected  for  advancing  to  the 
next  iteration.  Also  this  section  will  include  communicating  the  results  of  our  process  to 
this  point,  scheduling  subsequent  efforts,  and  assigning  priorities  for  subsequent  action. 

10.2  Results 

The  Results  of  the  System  Engineering  Group’s  analysis  of  pair-wise  comparison 
showed  that  The  Microsat  alternative  ended  up  with  the  highest  utility  score. 

In  the  minimizing  acquisition  cost,  point  design  had  higher  weighting  because  of 
ease  of  manufacturing,  adaptability  to  the  off  the  shelf  technology  wherever  possible,  low 
cost  in  testing  and  launch  integration,  and  being  less  complex.  On  the  other  hand  Amoebae 
and  Works  had  less  weighting  since  they  had  more  complexity  and  integrity  in 
manufacturing  and  testing. 

In  the  minimizing  operation  cost,  the  Microsat  had  higher  weighting  because  in  the 
tactical  scenario  it  can  be  operated  by  individual  mobile  units  and  it  may  not  need  complex 
and  integrated  control  units  compared  to  the  works.  Testing,  launch  integration, 
survivability  and  reliability  decreased  the  operational  costs.  On  the  other  hand  integrational 
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complexity  increased  the  difficulty  in  system  and  user  sides  in  terms  of  standardization, 
subsequently  resulted  in  higher  operational  cost. 

In  the  minimizing  retirement  cost,  ease  of  de-orbiting  and  ending  the  mission  life 
were  two  important  factors.  Under  these  conditions  Microsat  obviously  had  higher 
weighting  and  Works  had  lower  weighting. 

For  flexibility.  Amoebae  provided  features  of  modular  flexibility  that  allowed  it  to 
be  adopted  to  a  wide  range  of  missions  and  payload  configurations.  Also  it  could  easily 
satisfy  multiple  missions  simple  by  changing  sensors  and  software.  The  Works’  long  life 
limited  it  to  adopt  the  newly  arising  changes  in  the  space  environment.  On  the  other  hand, 
specialization  to  specific  missions  were  important  aspects  for  the  other  alternatives. 

For  availability,  the  Works’  multiple  payload  configuration  enabled  it  to  assign 
different  missions.  Also  because  of  long  mission  lifetime,  it  has  to  be  more  reliable  for  on¬ 
board  data  processing,  uplink  and  downlink  communications  systems.  Amoebae’s 
complexity  in  modular  integration  decreased  its  reliability. 

For  responsiveness,  miniaturized  standard  design  of  satellites  and  payloads  (mass- 
produced  and  deployable  in  dozens  of  units)  could  offer  responsiveness  to  newly  arising 
situations  in  tactical  environment.  Thus  Microsat  had  higher  weighting.  But  in  terms  of 
standardization  Amoebae  had  more  disadvantages. 

For  capability,  the  Works’  multiple  payload  configuration,  on-board  data 
processing,  and  operational  autonomy  made  it  more  capable  for  diflFerent  mission 
requirements  at  the  same  time.  The  other  three.  Family,  Microsat,  Point  design,  had  lower 
weighting  in  that  sense. 
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10.3  Sensitivity  Analysis 


According  to  scenarios  generated  in  system  evaluation  part  seven  sub-scenarios  are 
summarized  in  the  Table  10-1. 


Table  10-1:  Scenario  Summary 


Fleet  Cost 

1.  Microsat 

2.  Point  Design 

3.  Family  4. 
Ranking 

The  Works 

5.  Amoebae 

Most  Important 

1 

2 

3 

4 

5 

Acquisition  Cost 

Microsat 

Works 

Family 

Point 

Amoebae 

Operation  Cost 

Microsat 

Point 

Family 

Works 

Amoebae 

Retirement  Cost 

Microsat 

Family 

Point 

Amoebae 

Works 

Effectiveness 

1.  Microsat 

2.  The  Works 

3.  Family  4. 
Ranking 

Point  Design 

5.  Amoebae 

Most  Important 

1 

2 

3 

4 

5 

Flexibility 

Microsat 

Family 

Amoebae 

Point 

Works 

Availability 

Microsat 

Works 

Point 

Family 

Amoebae 

Responsiveness 

Microsat 

Point 

Family 

Works 

Amoebae 

Capability 

Microsat 

Works 

Point 

Family 

Amoebae 
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11.  Recommendations 


11.1  Recommendations  for  Continued  Investigation 

Initial  investigations  into  small  tactical  satellite  design  and  evaluation  focused 
efforts  (necessarily)  on  high-level  design  architectures.  This  high-level  approach 
accomplished  the  goals  of  ensuring  the  familiarity  of  Team  members  with  the  systems 
approach  to  design;  introducing  less  space-sawy  members  to  satellite  design,  production, 
and  operation;  serving  as  an  initial  “design  compass”  to  focus  not  on  specific  architectures, 
but  on  those  aspects  of  the  value  system  which  were  most  important;  and  to  provide 
insight  into  possible  implementation  schemes  for  the  final  design  combined  with  an  overall 
design  architecture  and  concept  of  operations  (CONOPS). 

After  evaluation  of  the  large-scale  satellite  concept  architectures,  the  system  design 
process  must  shift  its  focus  to  specific  satellite  design  exploration  and  the  incorporation  of 
those  aspects  of  the  value  system  which  provide  the  greatest  payoff  (as  concerns  the 
satellite  design).  This  process  will  involve  research  into  the  specific  subsystems  and 
specific  components  of  those  subsystems  and  their  impact  on  the  overall  satellite  as  a 
whole. 

Further  refinement  of  the  problem  definition  and  value  system  will  be  facilitated  by 
further  contact  with  the  sponsor,  space  and  industry  experts,  and  research  into  the 
individual  subsystems. 

System  modeling  and  evaluation  will  incorporate  a  computer-based  (MATLAB) 
design  tool  for  both  designing  and  evaluating  candidate  designs.  A  computer-based 
modeling  scheme  will  facilitate  the  convergence  of  candidate  designs  into  cohesive 
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systems,  as  opposed  to  collections  of  components.  This  approach  is  intended  to  converge 
on  potential  solutions,  based  on  Value  System  Design.  Current  architectures  will  be  used 
as  a  starting  point,  but  new  concepts  can  be  generated. 

The  concept  of  a  Microsat  certainly  lends  itself  to  small  launch  vehicles,  but  it  does 
not  necessarily  support  the  range  of  payloads  as  put  forth  by  the  sponsor.  Power 
requirement  is  a  big  variable  as  relates  to  a  potential  range  of  payloads.  The  task  of 
attitude  determination  and  control  is  no  small  chore  either,  since  varying  payloads  with 
their  necessary  power  support  can  significantly  alter  dynamics  from  one  configuration  to 
the  next.  It  seems  that  either  a  satellite  bus  must  be  overpowered  and  possess  over 
capable  dynamic  control  for  most  mission  modules  (The  Works),  or  these  factors  must  be 
alterables  in  the  form  of  interchangeable  components  (similar  to  Amoebae)  or  as  two  or 
more  basic  fixed  designs  (Family).  All  of  these  concepts  are  similar,  though,  since  some 
satellite  bus  is  on  hand  with  the  payload  required  to  fit  within  specifications  provided  by 
the  bus,  not  the  other  way  around. 
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PHASE  II 


12.  Introduction 


Subsequent  iterations  of  the  systematic  approach  lead  to  revisions,  clarifications, 
and  refinements  to  both  the  process  and  the  product.  The  team  learned  that  the  original 
systematic  approach  used  in  Phase  I  was  not  effective  in  narrowing  the  scope  of  the 
problem  and  developing  design  alternatives.  This  required  the  team  to  create  a  new 
process.  This  section  documents  the  team’s  work  in  applying  the  innovative  approach  to 
the  design  of  a  generic,  small  standardized  satellite  bus  for  tactical  applications. 

Phase  II  follows  the  outline  of  the  newly  created  systematic  approach  and 
discusses  the  changes  and  refinements  made  since  the  work  performed  in  Phase  I.  It  is 
assumed  that  the  reader  has  a  working  knowledge  of  the  new  design  process  being  applied 
and  is  cognizant  of  the  work  performed  in  the  first  iteration.  Specifically,  background  data 
and  definitions  of  the  process  are  not  included  in  this  section. 

This  section  documents  the  design  team’s  understanding  and  scope  of  the  problem 
as  refined  by  the  second  iteration  of  the  systematic  approach.  In  addition  to  providing  the 
details  on  the  refined  problem  statement  and  subsequent  changes  to  the  value  system 
design,  a  new  section  was  added  to  discuss  the  trade  studies  that  were  performed  on  both 
system  and  subsystem  levels.  The  section  also  provides  the  details  on  the  efforts  made  in 
the  creating  an  integrated  model  and  the  alternatives  that  were  created.  The  section 
concludes  with  an  in-depth  analysis  of  the  design  alternative  and  suggests  methods  for 
implementing  the  designs. 
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13.  Problem  Definition 


Gaining  insight  into  satellite  design  and  probing  the  different  aspects  of  the 
proposed  problem  were  the  main  focus  of  the  first  iteration.  In  the  second  iteration,  the 
team  focused  its  effort  on  studying  and  understanding  the  functions  of  the  satellite 
subsystems  and  examining  the  factors  that  influence  the  satellite  bus  design.  This  led  to  a 
more  detailed  examination  of  the  tasking  statement  and  the  factors  that  influence  the 
problem.  The  first  item  re-examined  was  the  problem  statement. 

The  team  examined  the  problem  statement  and  decided  that  the  word  ‘modular’ 
was  not  required  to  be  part  of  the  statement.  The  team  decided  that  being  modular  was 
more  of  a  design  option  rather  than  a  goal  of  designing  a  generic  satellite  bus.  The  team 
felt  that  by  including  ‘modular’  in  the  problem  statement,  the  number  of  possible  design 
alternatives  would  be  severely  limited.  The  word  was  removed  and  the  refined  statement 
is  provided  below.  The  new  statement  was  referred  to  throughout  the  design  process. 
This  ensured  that  the  team’s  efforts  remained  focused. 

13.1  Problem  Statement 

The  refined  problem  statement  reads; 

Design  a  rapidly  deployable,  tactically  oriented,  satellite  bus  to  enhance  theater 
operations.  This  satellite  bus  is  to  support  missions  in  the  Pegasus  and  Lockheed-Martin 
Launch  Vehicle  (LMLV)  weight  class. 
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13.2  System  Boundary 


Since  the  system  boundary  defined  the  elements  of  the  problem  that  could  be 
controlled  or  manipulated,  the  team  decided  that  the  best  way  to  narrow  the  focus  and 
scope  of  the  study  was  to  refine  this  area.  The  boundaries  were  divided  into  two  distinct 
environments;  an  external  environment  and  an  internal  environment.  Items  that  existed  in 
the  external  environment  influenced  the  solution  space  for  the  problem,  but  were  not  items 
that  the  design  team  could  control.  These  items  were  considered  outside  the  team’s  scope 
with  respect  to  redesigning  components  or  changing  concepts  of  operation.  Items 
contained  within  the  internal  environment  were  aspects  that  could  be  controlled  by  the 
design  team  and  were  subject  to  trade  studies.  Figure  13-1  provides  a  graphical 
representation  of  the  problem’s  system  boundaries. 
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The  external  boundary  was  comprised  of  the  following  items;  the  launch  vehicle, 
the  payload,  the  satellite  contractor,  the  mission  operations  concept,  space,  the 
constellation  design,  the  storage  and  inventory  concept,  and  the  Air  Force  Satellite 
Control  Network.  Aspects  of  each  element  are  described  below. 

•  The  launch  vehicle:  The  design  team  examined  the  system  requirements  for  placing 
the  vehicle  into  orbit.  The  team  decided  to  use  the  Pegasus  XL  launch  vehicle  for  this 
design  study.  Aspects  of  the  launch  vehicle  that  had  an  influence  on  the  satellite  bus 
design  were  launch  preparation  time,  mass-to-orbit  performance,  satellite-to-launch 
vehicle  integration  constraints,  and  fairing  constraints.  Launch  vehicle  development 
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and  integration  of  launch  vehicle  stages  were  outside  the  realm  of  the  design  team’s 
control  and  were  not  subjected  to  trades  or  redesign. 

•  The  mission  module:  A  number  of  different  mission  modules  were  examined.  These 
included  remote  sensing  payloads  such  as  multispectral  imaging  (MSI)  systems, 
synthetic  aperture  radar  (SAR)  systems,  infrared  (IR)  systems,  and  laser  designators. 
Specific  mission  modules  were  not  designed  by  the  team  to  be  integrated  onto  the 
generic  bus.  The  bus  design  was  influenced  by  the  mission  module’s  data 
storage/health  and  status  requirements,  thermal  loading,  power  requirements,  mission 
requirements,  and  required  pointing  accuracy’s. 

•  The  satellite  contractor:  A  satellite  company  has  a  definite  influence  on  the  design 
when  it  comes  to  manufacturing  the  actual  satellite  bus.  Additionally,  different 
companies  have  different  manufacturing  processes.  Due  to  the  prehminary  nature  of 
the  design  study,  the  team  considered  items  that  would  create  mahufacturing 
difficulties,  but  did  not  perform  extensive  research  into  actual  satellite  manufacturing. 

•  The  mission  operations  concept:  The  methods  the  United  States  Air  Force  (USAF) 
employs  to  perform  its  satellite  missions  had  an  influence  on  the  satellite  design.  The 
design  team  did  not  attempt  to  change  or  modify  the  way  the  USAF  does  business. 
However,  understanding  the  constraints  and  requirements  needed  to  perform  satellite 
operations  was  a  prerequisite  for  this  design  effort. 

•  Space:  This  was  the  actual  operating  environment  in  which  the  satellite  bus  would 
perform  its  mission.  It  was  important  that  the  design  team  understood  what  effects 
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space  could  have  upon  the  satellite  bus.  The  team  had  to  design  the  vehicle  in  such  a 
way  that  it  accounted  for  the  space  environment. 

•  The  constellation  design:  The  actual  use  of  the  vehicle  and  constellation  deployment 
was  left  to  the  satellite  user.  The  orbit  choice  and  number  of  satellites  to  be  placed 
into  orbit  will  be  contingent  upon  the  user’s  need.  The  team  provided  a  satellite  bus 
design  that  attempted  to  maximize  its  utility  to  the  user. 

•  The  storage  and  inventory  concept:  It  was  taken  as  an  assumption  that  the  satellite 
and  its  components  would  be  stored  and  maintained  in  an  appropriate  clean  room 
environment  while  the  satellite  was  on  the  ground.  Therefore,  the  team  did  not  design 
any  aspects  of  the  storage  and  inventory  process.  However,  consideration  was  given 
to  this  storage  and  inventory  process  when  design  alternatives  were  developed. 

•  The  Air  Force  Satellite  Control  Network  (AFSCNt:  Since  compatibility  with  the 
AFSCN  was  required  by  the  decision  maker,  aspects  associated  with  this  satellite 
control  network  had  a  major  influence  on  the  design.  Satellite  components  such  as 
receivers  and  transmitters  had  to  operate  at  Space  Ground  Link  System  (SGLS) 
frequencies.  The  team  made  no  attempts  to  redesign  any  aspect  of  the  AFSCN. 

Items  contained  within  the  internal  environment  included  the  satellite  bus 
subsystems,  the  launch  vehicle  interface,  and  the  mission  module  interface.  Operational 
concepts  directly  related  to  the  use  of  the  bus  were  considered  within  the  boundary  of  the 
system.  The  team  had  the  freedom  to  modify  concepts  such  as  on-orbit  command  and 
control,  mission  module  and  launch  integration,  and  sensor  data  processing.  The  team 
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decided  that  the  concept  of  having  two  different  on-orbit  command  and  control  systems  to 
the  satellite  was  well  within  the  scope  of  the  bus  design. 

13.3  Needs 

Further  revisions  were  also  performed  in  the  needs  area.  This  was  accomplished 
because  the  team  wanted  a  clearer  understanding  of  the  problem.  The  categorized  lists 
created  in  the  first  iteration  only  provided  generalized  groupings  of  the  needs.  A  deeper 
understanding  of  the  problem  required  more  definition  be  given  to  the  problems  needs.  It 
was  believed  that  if  a  needs  definition  could  be  tied  to  the  system’s  boundaries  or  the 
decision  maker’s  views  (Rooney,  1996),  it  would  offer  a  better  understanding  of  the 
problem.  The  refined  needs  definitions  are  provided  below  and  incorporate  the  sponsor’s 
views  or  the  system’s  boundary  considerations  as  appropriate. 

•  Mass:  The  satellite  design  had  to  be  optimized  to  support  as  many  mission  module 
types  as  possible.  Mission  modules  with  masses  between  23  and  114  kilograms  had  to 
be  supported  and  fit  within  the  constraints  of  a  Pegasus  XL  launch  vehicle.  It  was 
thought  that  better  designs  would  provide  more  mass  and  volume  to  the  mission 
module  yet  still  supply  ample  power  and  interfaces. 

•  Responsiveness:  Possible  design  alternatives  had  to  consider  the  rapid  launch  of  a 
satelhte  constellation.  The  bus/mission  module  combination  had  to  be  easily  integrated 
to  meet  the  need  for  rapid  deployability  and  tactical  applications. 

•  Sensors/mission  modules:  Different  mission  requirements  were  considered;  i.e., 
electro-optical  (EO),  infra-red  (IR),  laser  designators. 
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•  Pointing  accuracy:  The  question  of  pointing  accuracy  had  to  be  considered  when 
trying  to  achieve  1  meter  resolution  during  an  imagery  pass  of  5-10  minutes  per  orbit. 

•  Power:  The  satellite  design  had  to  support  peak  power  requirements  up  to  1  kilowatts 
and  average  power  requirements  of  300-500  watts. 

•  Orbital  maintenance:  The  satellite  had  to  operate  at  a  minimal  orbital  altitude  of  300 
kilometers  for  a  mean  mission  duration  of  12  months. 

•  Telemetry,  Tracking,  and  Command:  Satellite  design  alternatives  had  to  be  compatible 
with  the  AFSCN.  Data  downlinks  had  to  support  near  real-time  transmission  of  1 
meter  resolution  imageiy  data.  Encryption  and  deception  provisions  were  also 
required. 

•  Data  storage:  Designs  had  to  support  on-board  storage  of  up  to  100  images. 

•  Data  Processing:  Design  alternatives  had  to  support  minimal  on-board  processing  and 
data  compression  algorithms  for  transmission  of  images  to  ground  station. 

13.4  Mission  Module  Overview 

The  problem  involved  with  the  design  of  a  “generic”  satellite  bus  is  that,  because 
the  bus  is  to  be  generic,  it  cannot  be  designed  to  one  specific  payload  or  mission.  It  must 
support  the  requirements  demanded  by  all  foreseeable  missions  within  the  scope  of  the 
overall  design. 

13.4.1  Background  and  Scope 

The  payload  or  mission  equipment  of  any  spacecraft  is  generally  considered  to  be 
that  particular  spacecraft’s  reason  for  existing.  The  payload  is,  after  all,  comprised  of  the 
equipment  which  the  spacecraft  owners  and  users  desire  to  employ  (from  the  space 
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vantage)  for  the  collection  or  distribution  of  very  specific  mission  information. 
Consequently,  satellite  designs  in  the  past  have  always  focused  on  this  specialized 
equipment,  functionally  separating  it  from  the  rest  of  the  vehicle  (satellite  bus).  Within 
this  paradigm,  payloads  tended  to  be  as  large,  expensive,  and/or  as  powerful  or  capable  as 
possible.  The  bus  was  basically  designed  and  built  to  support  that  particular  payload  (i.e., 
the  bus  was  built  up  “around”  the  payload).  Thus,  because  of  the  specific  nature  of  a 
spacecraft’s  payload  equipment,  as  well  as  owing  to  the  fact  that  all  satellites  are  basically 
manufactured  by  hand,  individual  satelhtes  tended  (and  continue)  to  be  unique. 

Similarities  in  design  and  equipment  among  satellites  of  the  same  constellation  or  “family” 
are  more  numerous,  but  even  these  satellites  have  been  and  continue  to  be  dissimilar  in 
some  areas,  due  to  the  addition  of  features,  change  of  specifications,  or  flight  experience 
from  earlier  designs.  All  of  these  factors,  in  addition  to  the  slow  historical  launch  rate, 
tended  to  drive  up  costs.  A  “vicious  circle”  of  spiraling  costs  ensued  and  continues  today, 
driving  designers  to  build  fewer,  more  reliable,  more  capable,  and  larger  satellites.  The 
larger  vehicles  compounded  the  launch  availability  problem  due  to  the  fact  that  larger 
boosters  became  necessary  for  the  larger  vehicles  --  larger  boosters  take  longer  and  are 
more  costly  to  integrate. 

Shifting  equipment  and  design  focus  AWAY  from  the  payload  components  forces 
a  shift  in  the  spacecraft  design  paradigm.  It  focuses  on  the  vehicle  itself,  the  bus,  as  a 
starting  point  for  employment  of  special  sensors  or  other  equipment  from  space.  In  this 
paradigm,  the  payload  simply  becomes  yet  another  “component”  which  must  be  integrated 
into  the  vehicle  as  a  whole  --  the  payload  specializes  or  tailors  a  standard  vehicle  to  a 
specific  mission  or  purpose.  This  paradigm  is  analogous  to  a  multi-role  fighter  aircraft 
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being  outfitted  with  a  particular  weapons  load  for  the  performance  of  a  specific  mission. 
The  fighter  is  the  “standard  vehicle”  which  can  then  be  used  for  a  variety  of  missions. 

This  particular  paradigm  requires  the  payload  designer  to  produce  payload  equipment 
packages  which  can  seamlessly  interface  with  and  ‘1;ake  a  ride”  on  a  satelhte  bus  which  has 
already  been  designed  (or  built)  and  can  provide  all  the  payload  support  functions 
necessary. 

This  intimate  interface  between  the  payload  and  the  spacecraft  bus  then  becomes 
the  focus  of  design  efforts.  The  payload  equipment  package  (from  here  on  “mission 
module”)  must  conform  to  a  standard  set  by  the  bus  design;  however,  the  bus  must  be  able 
to  support  the  proper  functioning  of  the  mission  module  by  providing  (as  required  by 
specific  mission  type)  power,  data  and  command  handling,  thermal  protection  and/or 
isolation,  stability  and  pointing  accuracy,  structural  and  mechanical  integrity,  slew 
rate/accuracy,  and,  of  course  proper  orbital  position  over  the  surface  of  the  Earth. 
Therefore,  the  design  problem  further  distills  to  the  generation  of  a  “starting  point”  or 
baseline  set  of  mission  module  support  requirements  from  which  an  iterative  process  of 
bus-design-and-mission-module-interfacing  may  commence.  The  most  desirable 
conclusion  from  this  process  is  a  bus  design  that  not  only  meets  a  set  of  given  mission 
module  requirements,  but  also  supports  a  CONTINUUM  of  mission  module  requirements 
(i.e.,  non-discrete  requirements  values),  while  providing  a  set  of  standard  volumetric, 
mechanical,  data,  power,  and  thermal  interfaces  to  which  mission  modules  may  be 
physically  designed. 

But  where  to  start?  The  initial  starting  point  for  an  eventual  (desired)  continuum 
of  missions  must  start  with  a  standard  set  of  requirements  which  fully  span  the 
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“requirements  space”.  That  is,  a  good  initial  set  of  requirements  should  span  the  full  range 
of  foreseeable  requirements  which  the  bus  design  must  support.  It  follows  that  in  order  to 
derive  an  initial  set  of  requirements,  an  initial  set  of  missions  must  provide  sufficiency  in 
spanning  the  requirements  space.  These  mission  areas  must:  1)  define  the  initial  points 
from  which  requirements  estimation  relationships  (RERs)  may  evolve,  and  2)  be 
sufficiently  “expandable”,  thereby  providing  the  desired  continuum  or  range  of 
requirements  over  which  the  bus  architecture  and  design  iterate  and  converge. 

This  problem  is  well  suited  to  computer  model  support  because  of  the  iterative 
design  approach  which  this  problem  requires.  The  course  of  several  iterations  of  mission 
module  requirements  generation  combined  with  bus  design  attempts  (analogous  to  a 
Newtonian  or  similar  approach  to  numerical  estimation)  will  converge  a  solution  set  of  bus 
designs  as  candidates  for  further  (operational  effectiveness)  evaluation.  The  issue, 
however,  returns  to  the  fact  that  RERs  must  provide  the  requirements  inputs  to  the  model 
and  the  initial  set  of  missions  must  sufficiently  characterize  the  space  which  the  RERs 
must  span. 


13.4.2  Mission  Module  Support  Requirements 

The  basic  space  mission  type  is  an  Earth  observing  or  remote  sensing  mission; 
however,  this  simple  mission  type  is  further  subdivided  into  a  plethora  of  specific  sensing 
missions  directly  related  to  military  operations  and  directly  applicable  to  a  tactical  (in¬ 
theatre)  environment.  Furthermore,  within  this  general  mission  area,  one  finds  a  wide 
range  of  payload  equipment  and  sensors,  varying  in  mass  from  a  few  to  several  hundred 
kilograms  and  varying  in  power  requirements  from  a  few  to  several  hundred  kilowatts. 
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These  characteristics  make  this  space  mission  area  advantageous  to  the  task  of  generating 
initial  mission  requirements. 

The  next  step  in  defining  initial  mission  module  requirements  is  to  generate  some 
discrete  requirements  values  for  the  specific  mission  types.  The  specific  mission  module 
characteristics/requirements  under  consideration  and  of  concern  to  the  mission  module 
designer  may  include; 

•  electrical  power 

•  vibrational  stress 

•  thermal  stress 

•  thermal  isolation 

•  structural  integrity 

•  mechanical  interfaces 

•  electrical  interfaces 

•  telemetry  formatting 

•  equipment  volume 

•  equipment  mass 

•  data  throughput 

•  data  storage 

•  data  down-link 

•  platform  slew  rate 

•  platform  pointing 

•  platform  stability 

•  positional  (surface)  revisit 

•  positional  (orbit)  tolerance 

For  purposes  of  this  design  study,  the  grouping  of  requirements  into  larger  “requirements 
measures”  which  capture  the  meairingfulness  of  the  “bit  level”  parameters  facilitates 
generation  of  RERs  which  are  easily  modeled.  Additionally,  a  design  study  involving 
these  lower-level  requirements  is  beyond  the  scope  of  this  investigation.  Therefore,  it  is 
advantageous  to  attempt  to  either  capture  these  requirements  within  higher-level 
expressions  or  treat  them  as  ancillary  information  along  with  other  “payload  designer- 


84 


generated”  information  such  as  mission  module  costs.  Other  requirements  information 
may  be  treated  as  “built  into”  the  design,  such  as  vibrational  stress  and 
mechanical/structural  interfaces/integrity.  Thus,  a  “higher-level”  list  of 
characteristics/requirements  suitable  for  concept  exploration  may  include: 

•  available  power 

•  available  launch  mass 

•  available  launch  volume 

•  pointing/stability  requirements 

•  data  handling  requirements 

•  data  storage  requirements 

•  mission  data  down-link  support 

•  thermal  protection  and/or  isolation 


The  aspects  of  the  satellite-to-mission  module  interface  which  will  be  most 
important  to  the  mission  module  designer  will  be  mass,  volume,  power,  and  data  storage 
budgets  available  for  the  mission  module.  These  budgets  will  provide  the  mission  module 
designer  with  limits  within  which  the  mission-specific  equipment  must  operate. 

Similarly,  the  most  important  considerations  for  the  bus  design  will  be  the  support 
of  those  baseline  power,  mass,  stability,  pointing,  data  handling,  data  storage,  and  thermal 
isolation  requirements  necessary  to  accommodate  all  of  the  baseline  mission  module  types. 
These  types  include  applications  spanning  basic  electro-optical  radiometers,  multispectral 
imagers,  LASER/LIDAR  systems,  and  synthetic  aperture  RADARs.  These  mission 
module  types  were  chosen  for  their  diversity  and  their  applicability  to  tactical  space 
applications.  Because  of  the  generic  nature  of  this  study,  and  due  to  the  fact  that 
specifications  for  military  systems  (within  these  categories)  are  either  classified  or 
unavailable  at  this  time,  estimates  for  mass,  power,  volume,  and  other  specific 
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requirements  had  to  be  generated  from  experience,  remote  sensing  class  notes,  SMAD, 
and  the  few  analogous  commercial,  scientific,  and  civilian  applications  available  for 
inclusion.  For  purposes  of  this  design  study,  however,  which  focuses  on  the  design  of  a 
specific  satellite  bus  (not  the  mission  modules),  lack  of  specificity  of  mission  module 
designs  will  not  impact  the  overall  design  of  the  bus.  The  purpose  of  a  discussion  of 
mission  module  requirements  will  provide,  in  many  cases,  valuable  performance 
requirements  to  be  met  by  the  specific  subsystems  of  the  satellite  bus  (e.g.,  pointing 
accuracy  requirements  will  drive  decisions  made  about  attitude  control  system 
components).  In  all  cases,  extrapolation  of  estimates  was  conservatively  overestimated  in 
order  to  provide  sufficient  design  margins. 

13.4.3  Specific  Mission  Module  Types 

13.4.3.1  Electro-Optical  Imaging  (EO) 

The  least  expensive,  lightest  weight,  lowest  power,  and  probably  the  widest  used 
payload  type  for  tactical  missions  is  the  simple  yet  capable,  high-resolution  camera  system. 
Systems  of  this  type  gather  electromagnetic  (EM)  radiation  in  the  visible  (VIS;  -0.37- 
0.75  micron)  and  sometimes  ultraviolet  (UV:  -0.15-0.39  micron)  regions  of  the  EM 
spectrum.  The  military  utility  of  this  type  of  imagery  dates  back  to  the  first  days  of  placing 
observers  in  balloons,  and  later  placement  of  cameras  in  reconnaissance  aircraft.  One 
disadvantage  of  this  mission  module  type  is  that,  because  it  depends  upon  the  reflected 
illumination  from  the  Sun,  a  satellite  equipped  with  this  type  is  most  effective  in  Sun- 
synchronous  orbits  (see  orbit  tradeoffs  discussion). 
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The  configuration  for  this  basic  mission  module  type  consists  of  a  telescope 
housing  the  optics,  incorporating  a  compact  ‘Tolded”  optical  design,  and  a  sensor  suite 
housing  the  detectors  (a  charge-coupled  device,  or  “CCD”  array).  The  chosen  orientation 
for  this  mission  module  and  others  is  axial,  nadir-pointing  from  the  “top”  shelf  of  the 
spacecraft:  bus  orientation.  Estimations  are  based  conservatively  (i.e.,  overestimating  to 
provide  a  design  margin)  on  and  extrapolated  from  the  optics  package  and  cameras  used 
on  the  (1994)  Clementine  1  mission  and  proposed  for  the  (1998)  Clementine  2  spacecraft. 
These  high  resolution  cameras  were  originally  developed  for  use  on  board  small  satellites 
deployed  at  LEO  and  are,  therefore,  appropriate  to  this  design  study.  Estimations  use 
aperture  size  (in  centimeters)  as  the  basis  for  all  of  these  first-order  estimates  of  mass  and 
power.  These  estimates  will  vary,  of  course,  depending  on  individual  detector  size 
(anywhere  from  5-20  microns)  and  efficiency  of  optics  design/construction.  Overall  field 
of  view  (FOV)  for  these  systems  will  be  totally  driven  by  the  size  of  the  CCD  array.  For 
example,  a  system  with  an  instantaneous  field  of  view  (IFOV  —  the  FOV  for  one  detector) 
of  2.86  microradians  (one-meter  nadir  spatial  ground  resolution  from  a  350  km  orbit),  will 
require  a  1000  by  1000  detector  array  to  cover  a  1km  by  1km  ground  target.  Note  that  a 
payload  designer,  depending  on  the  performance  capabihties  desired,  determines  the 
specific  volumetric/mass  characteristics  for  a  mission  module  as  well  as  the  particulars  of 
the  arrangement  of  the  optics;  therefore,  estimation  relationships  are  intended  to  be  initial 
“first  order  starting  points”  if  no  specific  design  is  determined  ahead  of  time. 

Table  13-2  summarizes  some  estimated  EO  mission  modules  and  their 
characteristics.  Optical  diffiaction  limits  use  the  radiometric  resolution  equation 

(|)  =  l.ll’kfH  (Eqn  13-1) 
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where  (j)  is  the  IFOV  (in  radians),  X  is  the  wavelength  (in  meters)  of  the  EM  radiation 
gathered  by  the  optic,  and  D  is  the  aperture  (in  meters)  of  the  optic.  For  the  EO  mission 
module,  a  central  wavelength  of  0.5  microns  is  assumed. 

Table  13-2:  Electro-optical  (EO)  Mission  Module  Estimations 


Aperture 

(cm) 

Diffraction 

Resolution 

(prad/m) 

Mass 

(kg) 

Volume 

(m^) 

Power 

(w) 

30 

2.03/0.71 

23 

0.035 

7.5 

40 

1.53/0.53 

41 

0.082 

10.0 

50 

1.22/0.43 

64 

0.158 

12.5 

13.4.3.2  Multispectral  Imaging  (MSI) 

Advances  in  image  processing  as  well  as  improvements  in  detector  performance 
over  the  past  few  years  have  made  MSI  a  high-demand  payload.  The  MSI  mission  module 
uses  several  different  arrays  of  detectors  (CCD  arrays),  each  optimized  to  detect  a  specific 
band  of  EM  radiation.  Image  processing  produces  simultaneous  images  of  a  target  area 
characterized  at  various  regions  of  the  EM  spectrum.  These  regions  may  include  spectral 
bands  firom  UV,  visible,  NIR  (near  infrared;  ~0. 8-3.0  microns),  MIR  (middle  infrared: 

~3. 0-6.0  microns),  and  LWIR  (long- wave  (thermal  and  extreme)  infi'ared:  -6.0-30.0 
microns).  Intensity  levels  at  specific  wavelengths  may  indicate,  through  analysis,  a 
particular  activity,  characteristic,  or  object  within  the  field  of  view.  By  overlaying  and 
comparing  the  levels  of  intensity  at  specific  wavelengths  fi'om  a  single  target,  many 
characteristics  of  the  target  and  subsequent  target  identification  may  be  determined  by 
comparing  the  received  spectra  to  known  spectra  (predetermined  spectra  for  specific 
substances  --  a  particular  type  of  vehicle  paint,  for  instance).  Thus,  MSI  image  processing 
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and  analysis  is  related  and/or  analogous  to  spectroscopy,  in  which  the  characteristic 
elements  in  a  compound  may  be  discerned  by  comparing  (with  established  spectra  for 
suspected  elements)  the  spectra  returned  from  a  (bombarded)  sample.  Though  not  as 
dependent  upon  illumination  from  the  Sun  for  radiometric  sensing  (infrared  sensing, 
especially  thermal  imaging,  operates  effectively  on  the  night  side  of  the  Earth),  the  MSI 
mission  module  is  most  effective  in  a  Sun-synchronous  orbit,  due  to  its  normal  inclusion  of 
UV  and  visible  region  detectors.  These  orbit  considerations  will  vary,  in  accordance  with 
varying  detector  types  and  specific  mission  objectives. 

The  key  in  MSI  processing  is  the  “suspected”  ingredient  —  spotting  the  component 
spectra  which  best  “match”  those  returned  from  the  target  (this  is  basically  a  “pattern 
recognition”  problem  for  image  processing).  The  utility  to  military  planners,  of  course, 
will  be  the  ability  to  ignore  traditional  camouflaging  techniques  which  are  necessarily 
designed  to  subvert  visible  identification  (i.e.,  MSI  tactical  users  can  discriminate  between 
a  tank,  a  tank  under  camouflage,  and  a  decoy  tank  under  camouflage  —  all  due  to  subtle 
differences  in  spectral  characteristics).  Development  of  decoy  and/or  camouflage 
techniques  to  defeat  this  detection  scheme  will  prove  much  more  difficult  and  technically 
demanding  than  traditional  visible  camouflage  techniques  due  to  the  sophistication  of  the 
methods  involved.  Another  high  utility  function  of  the  MSI  payload  is  the  capability  to 
determine  minute  changes  in  a  target,  based  on  changes  in  the  spectral  characteristics  of 
the  target.  This  situation  is  analogous  to  taking  a  “before”  and  “after”  picture  of  an  object 
to  determine  changes  in  position,  motion,  heating,  cooling,  loading,  shape,  or  orientation. 

A  primary  performance  characteristic  for  these  systems  is  “spectral  resolution” 
which  gives  a  measure  of  the  bandwidth  of  one  spectral  sample  (pixel)  from  the  mission 
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equipment.  This  is  analogous  to  the  traditional  spatial  resolution  which  gives  a  measure 
(along  the  surface  of  the  Earth)  of  the  width  of  one  image  sample  (pixel).  As  the  spectral 
resolution  of  the  system  improves,  the  number  of  spectral  channels  (“bins”)  resolvable 
across  one  pixel  increases.  A  high  degree  of  spectral  resolution  provides  a  very  accurate 
spectral  mapping  of  the  target  area.  What  image  processing  experts  have  found  is  that, 
given  a  known  spectral  signature  for  an  object  and  sufficient  spectral  resolution  (channels), 
it  takes  significantly  fewer  pixels  to  spectrally  identify  that  object  than  it  would  take  to 
spot  the  same  target  using  a  (finer)  spatially-resolved  EO  system. 

MSI  payloads  can  use  the  same  type  of  optical  design  as  do  EO  payloads.  The 
difference  between  the  two  mission  module  types  resides  in  the  detector  types  and  support 
for  those  detectors,  as  well  as  the  wavelength  of  EM  radiation  to  which  the  optics  and 
detectors  have  been  optimized.  Detectors  that  share  optics  normally  share  optics  which 
have  been  simply  optimized  to  the  central  wavelength  of  the  full  range  of  the  detectors. 
Most  MSI  payloads  include  a  visible  EM  detector  to  include  with  the  other  detected 
wavelengths.  Basically,  the  MSI  payload  splits  the  target  irradiance  (received  by  the 
optics)  into  several  beams,  routing  specific  bandwidths  to  their  appropriate  detectors.  The 
routing  method  may  take  any  number  of  different  forms,  including  diffraction  gratings  (this 
tends  to  be  the  most  efficient  method),  prisms,  special  fiber  optic  cables,  or  elaborate 
reflection/transmission  optics.  Additionally,  for  thermal  imaging  detectors  (LWIR)  a 
varying  requirement  for  cryogenic  cooling  will  be  required,  depending  on  chosen  detector 
type,  semiconductor  material,  and  desired  sensitivity. 

Physical  characteristics  for  the  MSI  mission  module  are  similar,  but  more  massive 
and  more  power-hungry,  than  the  EO  mission  module,  due  to  the  additional  support 
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required  for  the  different  spectral  detection  bands.  Estimations  are  extrapolated  from  MSI 
payloads  based  on  the  Miniature  Sensor  Technology  Integration-3  (MSTI-3)  program  and 
the  MSI  sensor  suites  for  Clementine  missions  1  and  2.  As  with  the  EO  payloads,  the  will 
be  overestimated  when  compared  to  these  specific  examples  —  again,  accounting  for  a 
design  margin.  MSI  payload  characteristics  will  vary  according  to  specific  design  and 
performance  requirements,  and  the  estimations  account  for  this  likelihood  by  allowing 
initial,  first-order  estimates  on  mass,  power,  and  cost,  to  be  edited. 

Estimates  for  MSI  mission  modules  and  their  vital  characteristics  are  included  in 
Table  13-3. 


Table  13-3:  Multispectral  Imaging  (MSI)  Mission  Module  Estimations 


Aperture 

(cm) 

NIR  (1.5pm) 
Diffraction 
Resolution 
(prad/m) 

MIR  (4.0pm) 
Diffraction 
Resolution 
(prad/m) 

LWm.  (10.0pm) 
Diffraction 
Resolution 
(prad/m) 

Mass 

(kg) 

Volume 

(m^) 

Power 

(w) 

30 

6.1/2.135 

16.3/5.69 

40.7/14.23 

28.5'. 

0.039 

60.0 

40 

3.75/1.3125 

12.2/4.27 

30.5/10.68 

50.3 

0.089 

80.0 

50 

3.0/1.05 

9.76/3.42 

24.4/8.54 

78.7 

0.169 

100 

13.4.3.3  LASER/LID AR  Applications 

Using  optics  similar  to  the  EO  package  --  in  some  “functionally  dense”  mission 
modules,  the  VERY  same  optics  as  the  visible  camera/detector  —  the  LASER  imaging 
payload  adds  a  LASER  head  and  power  supply  (LASER  pump)  in  order  to  illuminate  a 
target  with  a  specific  wavelength  of  EM  radiation.  This  method  effectively  increases  the 
irradiance  (the  number  of  photons)  from  the  target  that  is  returned  to  the  detector,  thereby 
enhancing  imaging  performance  for  that  given  wavelength.  Concurrently,  due  to  the 
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coherence  of  the  returned  signals,  highly  accurate  ranging  and  range  rate  (velocity) 
determination  is  possible  (similar  to  a  RADAR).  Because  the  LASER  mission  module 
provides  its  own  illumination,  it  could  operate  effectively  in  orbits  other  than  Sun- 
synchronous  and  at  night,  making  it  more  tactically  available.  Due  to  the  narrow  beam, 
however,  LIDARs  are  not  normally  used  to  illuminate  or  track  moving  targets.  These 
mission  modules  can  produce  very  accurate  three-dimensional,  narrow-swath  imagery 
(especially  for  range  determination) ,  making  them  well-suited  for  topographical  missions 
and  atmospheric/meteorological  (cloud  system)  observations.  Of  course,  an  active  sensor 
system  such  as  this  will  require  much  more  power  than  passive  systems. 

A  major  drawback  for  the  LASER  or  LDDAR  system  is  atmospheric  attenuation  of 
the  LASER  light  illumination  from  the  spacecraft.  Atmospheric  attenuation  varies  with 
varying  wavelength  of  light  from  the  LASER.  Any  mission  designed  to  perform  active 
sensing  of  targets  on  or  near  the  Earth’s  surface  will  require  more  and  more  power 
pumped  into  the  LASER,  depending  on  the  desired  level  of  irradiance  incident  on  the 
target  and  the  wavelength  of  the  LASER.  Power  requirements  increase  substantially  if  the 
system  must  perform  its  mission  through  atmospheric  disturbances,  such  as  storm  clouds 
over  the  target.  This  increasing  power  requirement  will  drive  up  power  system  mass  and 
overall  spacecraft  mass  and  cost.  LASER  mission  estimators  are  based  on  the  LASER 
head  and  power  supply  flown  on  Clementine  1  and  proposed  for  the  Clementine  2 
spacecraft,  due  to  its  initial  development  for  LEO  applications  (these  LASERs  are  in  the 
100-200  watt  range  and  weigh  a  few  kilograms)  (BMDO,  1994;  Clementine  Team,  1996). 
These  estimators  provide  conservative  initial  values  for  mass,  size,  and  power,  which  may 
then  be  updated  if  more  accurate  specifications  are  known. 
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A  good  example  of  a  surface-sensing  topographical/meteorological  mission 
payload  is  a  proposal  for  a  NASA  spacecraft  for  launch  around  2000  (as  a  technology 
demonstration).  This  system  incorporates  a  500-watt  LASER  and  will  achieve  an 
estimated  altitude  accuracy  (of  surface  features)  of  one  to  two  centimeters  (NASA,  1995). 

LASER  technologies  also  may  extend  into  more  exotic  applications,  such  as 
extremely  high  data  rate  communications  packages  and  tactically-applied  LASER 
designation  systems  (see  Future  Technologies  and  Continuing  Investigations).  While 
these  experimental  and/or  developmental  applications  are  not  specifically  addressed  in  this 
design  study,  a  theoretical  mission  module  for  a  more  exotic  LASER  application  may  still 
be  modeled  by  simply  editing  the  pre-generated  estimates  for  mass,  power,  and  other 
characteristics.  Additional  mission  module  components  may  also  be  modeled  by  simply 
specifying  the  new  component  characteristics  and  adding  them  to  the  mission  module. 
Table  13-4  summarizes  some  estimated  LASER/LID AR  mission  modules  and  their 
characteristics. 


Table  13-4:  LASER/LIDAR  Mission  Module  Estimations 


Aperture  (m) 

LASER  Power  (w) 

Mass  (kg) 

Volume  (m^) 

Power  (w) 

30 

300 

38.7 

0.044 

318 

40 

250 

56.7 

0.089 

274 

13.4.3.4  Synthetic  Aperture  Radar  (SAR) 

By  far  the  payload  with  possibly  the  greatest  potential  tactical  “payoff”  is  the 
Synthetic  Aperture  RADAR  or  SAR  mission  module,  which  can  produce  very  high 
resolution  images  through  intensive  image  processing.  SAR  mission  modules,  like 
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LASER-based  mission  modules,  are  active  sensing  systems  and,  as  such,  generally  require 
an  order  of  magnitude  greater  power  to  operate  than  passive  systems  (EO  and  MSI). 

An  advantage  of  the  SAR  mission  module  is  that,  because  of  the  microwave 
frequencies  used  (typically  1-25  centimeters),  its  signal  is  much  less  susceptible  to 
atmospheric  attenuation.  SAR  sensing  capabilities  are  applicable  in  all  atmospheric 
conditions,  regardless  of  weather  over  the  target.  Additionally,  SAR  operates  effectively 
in  either  sunlit  or  night  conditions.  SAR  also  has  the  capability  of  imaging  underground, 
enclosed,  or  physically  covered  objects  by  penetrating  the  enclosures  or  ground  covers. 
This  day-night,  all-weather  capability  makes  SAR  a  highly  desirable  mission  module  type 
for  tactical  space  applications.  Tailoring  of  many  SAR  design  characteristics,  including 
power  level,  operational  wavelength,  physical  aperture  size,  antenna  gain,  and  pulse 
repetition  frequency  (the  rate  at  which  the  SAR  alternates  between  transmitting  and 
listening)  correspondingly  tailors  the  equipment  to  the  user’s  requirements  for  imaging  at 
different  resolution  settings  as  well  as  imaging  different  surfaces,  materials,  or  features 
(Brodsky,  1992:  pp.271-274).  If  the  antenna  for  the  SAR  is  steerable,  either  physically 
(gimballing  mechanisms)  or  electronically  (phased  array  architecture),  and  the  satellite  bus 
can  support  accurate  pointing  capability  (typically  ’within  0. 1  degrees  accuracy,  with  0.05 
degrees  attitude  knowledge),  the  SAR  may  perform  “spotlighting.”  Spotlight  mode  for  a 
SAR  trains  the  transmitted  beam  of  microwave  radiation  at  a  target  for  a  longer  period  of 
time,  mimicking  a  “staring”  system  and  producing  image  spatial  resolutions  generally  two 
times  to  four  times  better  than  a  SAR  mission  module’s  normal  operating  mode  (Rees, 
1991).  This  flexibility  makes  the  SAR  widely  applicable  to  missions  ranging  from  one- 
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meter  (or  better)  imaging  of  “normal”  targets  (such  as  buildings  or  vehicles)  to  weather 
pattern,  ocean  current,  and  wind  velocity  sensing  and/or  tracking  (NASA,  1995:  sec.  7). 

The  disadvantages  for  SAR,  as  applied  to  small  tactical  satellites,  include  the  fact 
that  a  SAR  requires  tremendous  amounts  of  power  (typically  greater  than  500  watts,  with 
still  greater  peak  output  requirements  for  enhanced  spotlight  and/or  boosted  signal 
modes),  and  the  fact  that  the  arrays  used  for  transmission/reception  of  the  microwave 
signals  have  to  be  large  (typically  10x2  meters)  in  order  to  provide  an  effective  antenna 
area  sufficient  to:  1)  cover  a  large  swath  and  2)  exhibit  good  gain  properties.  There  is  a 
classic  design  tradeoff  between  defocusing  the  antenna  for  coverage  and  requiring  a 
sufficient  signal  to  noise  ratio  for  the  desired  application.  Increasing  the  power  output  of 
the  SAR  also  serves  to  increase  the  signal  to  noise  ratio  of  the  system,  not  surprisingly, 
but  at  a  cost  of  a  higher  power  requirement  placed  upon  the  spacecraft  bus.  The  designer 
of  the  antenna  must  account  for  many  other  factors  (range  of  frequencies  to  be  used, 
polarization,  and  types  of  targets  to  be  sensed)  as  well. 

The  ultimate  application  of  the  mission  module  drives  much  of  the  SAR  design, 
and  for  a  SAR  package  to  be  made  as  small  as  possible,  the  designer  should  focus  on  a 
more  specialized  application.  The  more  specialized  the  mission  the  smaller  (more 
optimized)  the  package  may  be  made  (Jack-of-All  Trades  SAR  packages  have  tended  to 
be  quite  large  —  Canada’s  RADARS  AT  antenna  with  supporting  electronics  weighs  in  at  a 
whopping  total  mass  of  over  900  kilograms)  (NASA,  1995:  sec.  7). 

A  tradeoff  in  SAR  design  also  exists  with  the  selection  of  carrier  frequency.  A 
SAR  operating  at  higher  carrier  frequencies  is  better  able  to  discriminate  between  phase 
and  frequency  shifts  associated  with  the  Doppler  effect,  further  enhancing  resolution 
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precision;  higher  and  higher  microwave  frequencies,  however,  become  more  and  more 
susceptible  to  atmospheric  attenuation,  further  increasing  noise  effects.  More  signal  may 
be  provided  by  an  increase  in  transmitted  power  (as  stated  above),  thus  combating  the 
effects  of  atmospheric  losses.  With  these  considerations  in  mind,  the  tactical  SAR  mission 
module  should  include  a  high-power  (greater  than  500  watts)  SAR  operating  at  higher- 
frequencies  (Ku,  Ka,  or  X  bands,  a  wavelength  range  of  1-4  centimeters)  and  specifically 
tailored  for  the  tactical  military  role  of  all-weather  high-spatial-resolution  imaging 
(matching  or  exceeding  the  mission  and  performance  requirements  for  a  high-resolution 
EO  mission  module).  The  SAR  antenna  should  incorporate  a  spotlight  mode  by  utilizing  a 
phased  array  architecture  (saving  weight  by  using  fewer  mechanical  components). 

Mass  and  power  estimations  for  Modsat  are  based  on  a  lightweight  NASA  SAR 
payload  under  development  for  flight  by  the  year  2000.  This  equipment  will  incorporate  an 
electronically  steerable  phased  array  (10x3.5  meters)  along  with  the  transmitter/receiver 
electronics.  The  drive  for  this  technology  development  stems  from  the  need  for  smaller, 
lighter-weight  SAR  payloads  launchable  on  small  satellites  and  boosters  {Pegasus,  Taurus, 
LMLV).  The  applicability  of  SAR  technology  to  a  multitude  of  general  imaging  as  well  as 
scientific  applications  (mentioned  earlier)  drive  this  need.  The  proposed  package  requires 
under  500  watts  of  power  and  has  a  mass  of  under  100  kilograms  for  both  the  array  and 
RF  driver  electronics  (NASA,  1995:  sec.  7,  p.  22).  The  existence  of  this  technology 
development  makes  the  small  satellite  (Pcga5M5-launched)  SAR  mission  module  feasible 
for  consideration  in  this  design  study.  Further  mass  and  volume  reductions  may  be  made 
by  specializing  the  mission  module  performance  to  high-resolution  imagery,  as  well  as  by 
funding  a  more  aggressive  (i.e.,  military-focused)  technology  program  (the  proposed 
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technology  program  is  aggressive  in  approach,  but  its  focus  is  on  general  Earth-science 
applications). 

As  with  the  other  payload  types,  the  SAR  support  requirements  are  highly 
dependent  upon  the  intended  use  of  the  mission  module  and  the  designer’s  choices.  Initial 
SAR  equipment  estimation  will  vary  according  to  the  designer’s  wishes,  accounting  for 
the  variation  in  mission  module  characteristics.  Some  estimated  SAR  mission  modules 
(with  stowed  antenna  ~  launch  configuration)  are  summarized  in  Table  13-5. 


Table  13-5:  Synthetic  Aperture  RADAR  (SAR)  Mission  Module  Estimations 


Antenna  Dimensions  (m  x  m) 

Mass  (kg) 

Volume  (m^) 

Power  (w) 

8.0  X  1.5 

78.4 

0.318 

800 

10.0x2.0 

86.5 

0.564 

450 

13.4.4  Generally  Specified  Mission  Module  Support  Requirements 

Though  the  aforementioned  mission  module  types  are  varied  in  both  type  and 
specification,  there  are  certain  requirements  on  the  bus  which  may  be  specified,  allowing 
components  in  many  of  the  spacecraft  subsystems  to  be  chosen  for  all  candidate  designs. 
The  requirements  specifiable  through  mission  module  consideration  include  stabilization 
control,  pointing  accuracy,  attitude  knowledge,  thermal  isolation,  operating  power,  data 
handling,  data  storage,  and  data  down-link. 

Data  rates  of  specific  mission  modules  will  depend  on  the  number  of  image  pixels 
processed  every  second  as  well  as  the  dynamic  range  assigned  to  each  pixel.  For  a  basic 
“pushbroom”  linear  detector  array  (electro-optical  payload)  integrating  1024  (Ik)  pixels 
every  130  microseconds  (approximately  one-meter  spatial  resolution  from  a  350  kilometer 
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orbit),  the  data  rate  for  16-bit  (2-byte)  dynamic  range  is  16.8  megabytes  per  second 
(Mbytes/s).  Error  correction  coding  effectively  doubles  the  data  rate  (in  the  case  of  the 
example)  to  33.6  Mbytes/s  (Brodsky,  1992:  p.275).  Incorporating  10  spectral  channels 
(across  each  pixel)  into  this  example  calculation  (estimating  a  very  high  capacity  MSI 
payload),  the  data  rate  skyrockets  to  336  Mbytes/s.  SAR  images  include  not  only 
intensity  levels  in  every  image  pixel,  but  also  azimuth,  elevation,  range,  frequency,  phase, 
and  timing  information,  amounting  to  several  bytes  per  reconstructed  (synthesized)  image 
pixel.  Typical  data  rates  for  SAR  payloads  are  above  100  Mbytes/s.  The  spacecraft  bus 
must  be  able  to  accommodate  these  high  data  rates.  As  a  minimum,  the  satellite  bus 
should  be  able  to  handle  on-board  data  rates  from  the  payload  in  excess  of  150 
Mbytes/sec.  Higher  on-board  data  rates  may  be  supported  by  additional  data  buffers 
supplied  with  the  mission  module  (i.e.,  higher  data  rates  than  those  ultimately  set  by  the 
bus  design  become  “mission  specific,”  and  the  additional  components  required  for  support 
of  these  higher  rates  then  become  one  of  the  mission  module  design’s  requirements). 

Data  storage  capacity  requirements  will  vary  according  to  both  the  type  of  mission 
module,  its  data  collection  rate,  data  compression  scheme,  and  data  down-link  scheme.  A 
down-link  scheme  intended  to  transmit  data  in  near-real-time  may  require  the  bus  to  carry 
a  modest  storage  device  (like  the  solid  state  data  recorder  (SSDR)  carried  by  Clementine 
1)  of  1  or  2  Gbytes  storage  capacity.  A  high  data  rate  mission  module  or  a  higher  data 
latency  down-link  may  require  substantially  more  data  storage  capacity,  but  the  2  Gbyte 
SSDR  should  be  considered  a  minimum.  Data  compression  rates  typically  average  four- 
to-one,  compressing  16-bits  into  four,  but  may  range  up  to  12;  1  or  even  20: 1 .  The 
tradeoff  with  data  compression  schemes  is  that  with  increasing  compression,  the 
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probability  of  data  loss  increases.  More  discussion  of  data  down-linking  and  data  storage 
may  be  found  in  the  Command  and  Data  Handling  section. 

All  of  the  various  types  of  mission  modules,  all  of  which  are  imaging  systems,  will 
require  a  high  degree  of  pointing  accuracy,  attitude  knowledge  and  stabilization. 
Depending  on  the  specific  mission  module,  these  requirements  may  differ,  but  they  will  all 
require  pointing  accuracy  on  the  order  of  0. 1  degrees  and  attitude  knowledge  on  the  order 
of  0.05  degrees.  As  a  requirements  example,  the  Clementine  2  spacecraft  will  be  designed 
to  accuracy  and  knowledge  values  of  0.05  and  0.03,  respectively.  Accuracy/knowledge 
requirements  of  0.1/0.05  should  be  considered  maximum  allowable  margins  and  should  be 
taken  as  an  attitude  system  design  goal.  This  range  of  attitude  precision  will  require  a 
three-axis  stabilized  spacecraft  bus. 

Finally,  if  one  bus  must  be  able  to  support  a  wide  range  of  mission  module  types,  it 
must  be  able  to  supply  sufficient  power  (both  average  and  peak  power  requirements).  The 
greatest  differences  in  power  requirements  may  be  seen  by  comparing  the  passive  sensors 
(EO  and  MSI)  the  active  sensors  (LASER  and  SAR).  The  active  sensor-equipped  mission 
modules  will  require  substantially  more  power  from  the  bus  than  will  the  passive  sensor- 
equipped  ones  (several  hundred  watts  for  the  active  sensors  compared  to  about  100  watts 
maximum  for  the  passive  sensors).  The  highest-demand  mission  module  design  will  most 
likely  be  a  SAR-equipped  module  with  a  peak  power  of  greater  than  500  or  700  watts  (for 
its  spotlight  mode).  The  design  of  the  power  systems  for  the  spacecraft  bus  must  account 
for  these  possibly  very  high  peak  power  requirements. 

In  conclusion,  all  design  requirements  that  the  bus  must  meet  will  be  driven  by  the 
most  demanding  mission  module  type  in  all  cases.  Furthermore,  because  of  the  lack  of 
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specificity  of  mission  module  designs,  those  driving  design  requirements  must  necessarily 
be  interpreted  “ranges”  of  values,  as  opposed  to  exact  quantities.  Table  13-6  summarizes 
the  requirements  necessary  for  support  of  the  various  mission  module  types. 


Table  13-6:  Estimated  Mission  Module  Support  Requirements 


Bus  Performance  Criteria 

Mission  Module  Support  Requirement 

Pointing  Accuracy 

0.2-0. 1  degrees  or  better 

Attitude  Knowledge 

0.07-0.05  degrees  or  better 

Data  Compression 

4: 1  minimum 

Data  Storage  Capacity 

2Gbytes  minimum;  modular  unit 

Data  Handling  Capacity 

150  Mbytes/s  or  better 

Thermal  Environment 

thermally  isolated  from  mission  module 

Available  Mission  Power 

peak  power  from  500-900  watts 

Available  Mission  Launch  Mass 

120  kg  or  better 

Available  Mission  Launch  Volume 

0.6  m^  or  better 

13.5  Other  considerations 

No  further  changes  or  refinements  were  made  to  the  other  sections  of  problem 
definition.  The  satellite  design  team  used  the  data  presented  in  the  first  iteration  for  the 
alterables,  constraints,  and  actors. 
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14.  Value  System  Design 


14.1  The  Evolution  of  the  Value  System  Design 

In  the  first  phase  the  study,  the  objectives  were  treated  as  conceptual  attributes  by 
which  to  subjectively  compare  the  alternatives.  As  the  study  progressed  to  a  more 
detailed  level,  the  team  emphasized  the  need  to  use  measurable  objectives  as  much  as 
possible.  In  phase  two,  the  initial  set  of  objectives  was  overhauled  in  an  effort  to  create  a 
more  objective  fi-amework  for  measuring  the  performance  of  the  alternatives.  The  team 
added  subobjectives  with  specific  measures  of  effectiveness  that  could  be  obtained  through 
modeling  and  analysis. 

Moreover,  the  value  system  was  modified  to  account  for  feedback  from  the  CDM, 
advancements  in  system  modeling,  and  maturity  of  subsystem  engineering.  The  first  phase 
considered  that  the  main  objectives  were  cost  and  effectiveness,  in  order  to  capture  the 
classic  tradeoff  between  these  two  attributes.  As  the  study  progressed,  it  was  seen  that 
the  effectiveness  branch  of  the  hierarchy  should  be  decomposed  into  several  main 
objectives  that  would  capture  the  various  qualities  of  effectiveness.  Availability  was 
retained  as  a  main  objective.  Responsiveness  was  re-labeled  as  tactical  responsiveness  in 
order  to  emphasize  the  tactical  nature  of  the  spacecraft  bus.  The  qualities  of  flexibility  and 
capability  were  captured  under  the  new  main  objective  of  maximizing  mission  utility. 
Finally,  the  minimization  of  program  risk  was  added  as  a  main  objective. 

For  the  objective  of  minimizing  cost,  phase  one  considered  only  monetary  value. 
Phase  two  expanded  the  notion  of  cost  to  consider  time  and  effort.  The  objective  to 
minimize  the  time  to  full  rate  production  was  added,  while  the  operations  cost  sub- 
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objectives  were  evaluated  by  assessing  the  effort  required  to  carry  out  the  tasks.  Under 
operations  cost,  the  objective  to  minimize  maintenance  cost  was  added  to  account  for  the 
effort  required  to  keep  stored  busses  and  components  in  mission  ready  condition. 

Under  the  new  main  objective  to  maximize  mission  utility,  several  specific 
performance  objectives  were  added  to  enhance  the  evaluation  of  mission  capability. 

Under  the  availability  objective,  the  potential  for  overlapping  attributes  was 
decreased  by  consolidating  the  relevant  attributes  under  reliability  (natural  threats  and 
environmental  effects)  and  survivability  (man-made  threats). 

Under  tactical  responsiveness,  the  objective  to  minimize  turn  around  time  to 
launch  was  found  to  cover  areas  that  are  beyond  the  scope  of  this  study,  such  as  launch 
vehicle  operations,  operational  procedures,  and  issues  regarding  the  structure  and 
manpower  of  the  necessary  operational  Therefore,  this  objective  was  changed  to  the 
objective  of  minimizing  preparation  time  to  launch,  in  order  to  capture  those  elements  of 
the  alternative  concepts  that  are  relevant  to  the  study  and  affect  this  important  attribute. 

The  responsiveness  sub-objective  of  minimizing  time  for  data  was  changed  to  the 
objective  of  minimizing  of  data  latency.  The  original  definition  included  elements  that 
were  beyond  the  scope  of  this  study,  such  as  ground  communication  and  ground 
processing.  The  new  definition  concentrates  only  on  the  relevant  aspects  of  the  spacecraft 
bus,  such  as  data  processing  and  data  down-linking  architectures. 

The  objective  to  maximize  the  capability  for  tactical  maneuvers  was  added  under 
the  tactical  responsiveness  objective,  in  order  to  emphasize  the  desire  of  the  CDM  for  a 
tactical  platform. 
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Under  the  new  objective  of  minimizing  program  risk,  sub-objectives  were  added  to 


cover  the  areas  of  cost,  schedule,  and  performance  risk. 


14.2  Modsat  Objectives 

The  set  of  objectives  used  for  this  study  is  intended  to  fully  capture  the  values  of 
the  CDM  and  provide  a  consistent  framework  for  the  evaluation  of  alternatives.  Thus,  all 
of  the  objectives  discussed  below  were  used  to  guide  the  development  of  subsystem  and 
system-level  solutions.  Throughout  the  design  of  the  overall  system,  many  tradeoffs  were 
performed  at  the  system  and  subsystem  levels,  in  an  effort  to  form  a  reasonably  sized 
solution  space  within  which  alternative  system  solutions  could  be  evaluated.  As  a  result, 
the  remaining  alternative  solutions  satisfy  several  of  the  objectives  equally  well.  Although 
these  objectives  do  not  contribute  to  the  determination  of  the  best  solution,  they  were 
instrumental  in  the  development  of  each  candidate. 

The  main  objective  of  the  Modsat  study  was  to  produce  the  best  standardized  bus 
for  small,  tactical,  low-earth  orbit  satelUtes.  The  top-level  objectives  are  shown  in  Figure 
14-1.  The  following  sections  explain  each  objective. 
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Figure  14-1:  Top-level  Objectives 
14.3  Measures  Of  Effectiveness 

Each  bottom-level  sub-objective  has  a  unique  measure  of  effectiveness.  The  ideal 
MOE  is  a  natural  scale  which  can  be  directly  measured  or  computed,  such  as  speed  in 
meters  per  second.  However,  the  true  MOE  is  often  difficult  and  impractical  to  obtain. 
This  is  especially  true  for  studies  which  occur  early  in  the  life-cycle  of  a  system,  where 
modeling  and  testing  is  limited.  In  this  case,  two  options  are  available  (Clemen,  1996:79). 
The  first  is  to  use  a  proxy  measurement.  The  proxy  should  be  closely  related  to  the 
objective  under  consideration.  The  second  option  is  to  “construct  an  attribute  scale  for 
measuring  achievement  of  the  objective”  (Clemen,  1996:79).  This  requires  the  definition 
of  levels  of  performance  for  the  objective,  with  levels  ranging  from  best  to  worst. 
According  to  Clemen, 

The  key  to  constructing  a  good  scale  is  to  identify  meaningful  levels, 
including  best,  worst,  and  intermediate,  and  then  describe  those  levels  in  a 
way  that  fully  reflects  the  objective  under  consideration.  The  descriptions 
of  the  levels  must  be  elaborate  enough  to  facilitate  the  measurement  of  the 
consequences  (Clemen,  1996:80). 

Several  of  the  MOEs  for  this  study  are  actually  combinations  of  proxy 
measurements  and  attribute  scales.  For  instance,  all  sub-objectives  of  the  objective  to 
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minimize  pre-launch  operations  cost  are  measured  by  an  attribute  scale  that  determines  the 
difficulty  of  performing  the  task,  as  opposed  to  the  actual  dollar  cost  of  performing  the 
task.  All  attribute  scales  used  for  this  study  have  six  levels,  from  zero  (worst)  to  five 
(best).  It  was  felt  that  six  levels  provided  enough  detail  to  make  intelligent  judgments. 
Also,  the  scale  from  zero  to  five  translates  well  into  the  common  utility  scale  of  zero  to 
one  (discussed  in  section  14.5). 

The  MOEs  for  each  objective  are  described  in  section  14.4.  Included  for  several 
of  the  objectives  are  the  contributing  factors  that  aided  in  the  construction  of  attribute 
scales.  For  some  of  the  attribute  scales,  it  was  not  necessary  to  fully  define  all  six  levels, 
since  the  definition  of  the  best  and  worst  levels  made  it  clear  how  the  intermediate  levels 
would  be  defined. 

Although  most  of  the  MOEs  are  constructed  attribute  scales,  future  design  efforts 
for  this  program  must  convert  these  to  natural  scales  wherever  possible. 


14.4  Objective  Hierarchy 

14.4.1  Minimize  Cost 

The  sub-objective  hierarchy  under  “Minimize  Cost”  is  shown  in  Figure  14-2.  For 
this  study,  cost  is  made  up  of  two  main  elements.  The  first  element  is  monetaiy  cost.  The 
performance  of  each  monetary  cost  objective  may  not  be  measured  in  actual  dollars;  for 
some  objectives  a  proxy  utility  scale  will  describe  the  cost.  For  others,  cost  estimating 
relationships  (CERs)  may  be  used  where  such  relationships  are  available.  CERs  yield  a 
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cost  in  dollars,  but  all  such  costs  must  be  stated  for  the  same  year  (i.e.,  FY96  dollars). 
The  second  main  element  of  cost  is  time  to  foil  rate  production. 
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Figure  14-2:  Cost  Objectives 
14.4.1.1  Minimize  Monetary  Cost 

Monetary  cost  has  several  elements,  discussed  below.  Some  key  points  that  were 
kept  in  mind  when  evaluating  costs  for  this  study  were: 

•  Avoid  overlapping  and  double-counting.  Without  careful  accounting,  the  various 
elements  of  development,  production,  and  operations  cost  can  be  easily  counted  more 
than  once  under  different  calculations.  This  would  inflate  the  overall  estimation  of 
cost,  and  would  tend  to  make  the  cost  objective  appear  more  critical  than  it  would  be 
otherwise. 

•  Use  the  same  fiscal  year  base  for  dollar  values. 
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•  The  use  of  any  CER  must  be  validated  as  to  its  applicability  to  the  problem.  The  use 
of  irrelevant  CERs  can  lead  to  serious  errors  in  cost  estimation  For  example,  CERs 
for  the  radio  equipment  of  different  aircraft  types  may  be  similar,  but  the  engine  CERs 
for  a  bomber  and  a  fighter  could  be  quite  different.  The  two  types  of  engines  are 
designed  to  satisfy  very  different  demands.  Thus,  the  use  of  bomber  engine  CERs  for 
fighters  could  cause  inaccurate  estimations. 

•  This  preliminary  design  study  is  not  an  appropriate  forum  for  a  highly  detailed  cost 
analysis.  Any  generated  cost  values  were  intended  for  comparing  the  relative  program 
element  costs  of  competing  alternative  solutions,  and  should  not  be  interpreted  as 
actual  predicted  costs  for  the  spacecraft  bus. 

•  Cost  values  for  recurring  and  non-recurring  costs  are  not  additive,  and  must  not  be 
added  together  in  attempt  to  find  an  overall  cost.  Alternative  solutions  will  be 
evaluated  separately  for  each  attribute. 

There  are  four  main  sub-objectives  under  “Minimize  Monetary  Cost”: 

14.4.1.1.1  Minimize  Research,  Development,  Test  and  Engineering  (KDT&E)  Cost 

This  category  includes  all  non-recurring  costs  from  the  beginning  of  the  project  to 

the  production  effort. 

MOE:  Cost  estimating  relationship 

14.4.1.1.2  Minimize  Bus  Production  Cost 

This  objective  covers  the  cost  of  manufacturing  the  final  product. 

MOE:  Cost  estimating  relationship 


107 


14.4.1.1.3  Minimize  Retirement  Cost 


A  complete  spacecraft  design  effort  should  consider  disposal  of  the  spacecraft  at 
the  end  of  its  useful  life.  The  spacecraft  could  be  retired  via  reentry  into  the  atmosphere 
(by  natural  orbital  decay  or  by  a  AV  maneuver),  or  by  placement  into  a  “retirement”  orbit. 
The  method  of  retirement  will  dictate  the  cost.  For  instance,  a  AV  bum-in  requires  the 
reservation  of  propellant  for  retirement  purposes.  On  the  other  hand,  it  can  be  done 
quickly.  A  natural  decay  retirement  requires  no  propellant,  but  will  tap  space  operations 
resources,  as  personnel  and  equipment  must  be  used  to  keep  track  of  the  useless 
spacecraft. 

MOE:  Attribute  scale 
Contributing  factors: 

-  Amount  of  excess  fuel  for  retirement  purposes 

-  Time  required  to  track  the  dead  satellite 

-  Hazards  to  environment/people 

5  Satellite  can  be  retired  quickly  after  its  useful  life  is  gone;  retirement 
procedure  is  simple;  no  significant  hazards  to  environment/people. 

0  Dead  satellite  will  remain  in  orbit  for  years  before  retirement;  complex 
procedures;  significant  hazards  to  environment/people. 

14.4.1.1.4  Minimize  Operations  Cost 

This  cost  can  be  divided  into  pre-  and  post-launch  costs. 
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14.4.1.1.4.1  Minimization  of  Pre-Launch  Operations  Cost 

This  is  the  sum  of  all  ground  expenditures  necessary  to  prepare  the  satellite  for 
launch.  Since  this  study  occurred  as  a  first  step  in  the  potential  life-cycle  of  the  tactical 
bus  program,  the  performance  of  the  pre-launch  operations  cost  subobjectives  cannot  be 
realistically  measured  in  dollars.  Rather,  they  can  each  be  evaluated  by  proxy  attributes. 
The  sub-objectives  for  this  cost  are; 

14.4.1.1.4.1.1  Minimize  Cost  of  Mission  Module  Integration  and  System  Test 

This  cost  covers  all  efforts  to  mate  the  mission  module  to  the  bus,  and  to  test  the 
integrated  satellite.  There  are  various  manpower,  equipment,  software,  and  overhead 
costs  associated  with  coimecting  the  power,  signal,  thermal,  and  structural  interfaces.  The 
testing  effort  includes  all  actions  to  ensure  the  integrated  satellite  is  ready  to  be  shipped 
for  launch. 

Proxy;  Maximize  Ease  of  Mission  Module  Integration  and  System  Test 
MOE;  Attribute  scale 
Contributing  factors; 

-  Complexity  of  bus/mission  module  interface 

-  Complexity  of  total  spacecraft 

-  Number  of  components  and  parts 

-  Accessibility  of  components  and  connections 

-  Number  of  connections  and  cables 

-  Number  of  possible  configurations 

-  Complexity  of  signal  flows  (power,  data) 

5  Easy  to  integrate  and  test;  simple  bus/mission  module  interface;  few 
components  and  parts;  few  cables  and  connections;  few  subsystem 
interfaces;  total  accessibility  of  all  components  for  diagnostic  testing;  one 
standard  bus  configuration. 
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0  Extremely  difficult  to  integrate  and  test;  highly  complex  bus/mission 

module  interface;  many  components  and  parts;  abundant  and  complicated 
system  of  cables  and  connections;  components  are  highly  inaccessible; 
many  possible  system  configurations;  complex  system  of  signal  flows. 

14.4.1.1.4.1.2  Minimize  Cost  of  Storage,  Handling,  and  Transportation 

Includes  facilities,  equipment,  special  procedures,  manpower  and  overhead. 
Proxy;  Maximize  Ease  of  Storage,  Handling,  and  Transportation 
MOE:  Attribute  scale 
Contributing  factors: 

-  Number  of  sensitive  parts  needing  special  care  while  storing,  handling, 
and  transporting 

-  Amount  and  complexity  of  special  equipment  required  to  store,  handle, 
and  transport 

-  Special  requirements  for  storage,  handling  and  transportation  (i.e.,  clean 
room  requirements) 

-  Number  and  severity  of  required  safety  precautions  (i.e.,  hydrazine 
propellant  is  very  hazardous) 

-  Amount  of  storage  time  required  for  parts  and  assembled  busses. 

-  Classification  of  program 

5  Standard  clean  room  practices  for  storage  and  assembly;  no  extra  sensitive 
parts;  minimum  basic  safety  precautions;  no  unusual  equipment  required 
to  handle  parts;  no  special  classification  difficulties;  standard  inventory- 
supply  system  to  track  and  store  parts  and  assembled  busses;  minimum 
storage  time  required;  no  unusual  transportation  requirements. 


0  Very  strict  storage  requirements  (vacuum  chamber,  nuclear  durable,  etc.); 
many  highly  sensitive  components;  many  complicated  safety  precautions; 
highly  unique  procedures  and  equipment  required;  highly  unique 
inventory-supply  system  required;  special  classification  difficulties. 
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14.4.1.1.4.1.3  Minimize  Cost  of  Maintenance 


There  are  various  costs  associated  with  maintaining  the  spacecraft  hardware  and 
software,  including  manpower,  spares,  and  supplies.  This  covers  both  periodic 
maintenance  and  repairs.  Since  the  operations  concept  includes  the  storage  of  several 
busses,  periodic  maintenance  checks  will  be  necessary  to  support  the  equipment.  This  is 
especially  true  for  those  components  that  may  have  a  relatively  short  shelf-life. 

Proxy  MOE.  Maximize  Ease  of  Maintenance 
MOE;  Attribute  scale 
Contributing  factors: 

-  Amount  of  maintenance  required 

-  Accessibility  of  components 

-  Cost  and  Availability  of  parts 

-  Subcontractor  warranty  policies 

-  Shelf  of  life  parts 

-  Expected  storage  time  of  unassembled  components 

-  Expected  storage  time  of  assembled  components 

-  Complexity  of  design 

5  Minimum  inventory;  all  parts  ordered  just  prior  to  assembly;  assembled  bus 
quickly  integrated  with  mission  module  and  shipped  for  launch;  highly 
robust  parts  and  design,  requiring  very  httle  routine  maintenance;  simple 
bus  configuration,  with  easy  accessibility  to  components;  components 
readily  available  and  not  overly  expensive;  components  under  warranty; 
infinite  shelf-life  of  parts. 

4  Small  inventory;  some  storage  time  required  for  parts  and  assembled 
busses;  robust  parts  and  design;  some  routine  maintenance;  simple-to- 
moderately  complex  bus  design;  easily  accessibility  to  components; 
components  readily  available  and  under  warranty;  long  shelf-life. 

3  Small-to-moderate  inventory;  moderate  storage  times  required;  some 

routine  maintenance;  moderately  complex  design;  some  accessibility  to 
components;  components  available  with  short  lead  times;  moderate  shelf- 
life. 
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2  Moderate  inventory;  moderate-to-long  storage  times;  much  routine 

maintenance;  complex  design;  difficult  to  access  components;  moderate 
lead  times;  marginal  shelf-life. 

1  Large  inventory;  long  storage  times;  much  routine  maintenance;  complex 
design;  very  difficult  to  access  components;  long  lead  times;  short  shelf-life. 

0  Large  inventory,  with  many  components  held  for  a  long  time;  long-lead 
time  required  for  delivery  of  parts;  expensive  parts;  assembled  bus  held  in 
storage  for  many  months;  parts  break  before  needed,  and  not  covered 
under  warranty;  complex  bus  design  requiring  extensive  routine 
maintenance;  components  highly  inaccessible. 

14.4.1.1.4.1.4  Minimize  Cost  of  Launch  Integration  and  Test 

This  covers  all  efforts  to  mate  the  satellite  to  the  launch  vehicle,  and  to  test  the 
loaded  rocket. 

Proxy:  Maximize  Ease  of  Launch  Integration  and  Test 
MOE:  Attribute  scale 
Contributing  factors: 

-  Complexity  of  LV-to-spacecraft  interface 

-  Sensitive  parts  requiring  special  care  and  precaution,  such  as  spacecraft 
propellants,  solar  arrays,  antennas,  sensors,  etc. 

-  Special  integration  considerations 

-  Number  of  connections  for  power  and  data  flow 

-  Difficulty  of  testing  the  integrated  spacecraft 

-  Rigidity  of  structure 

5  Simple  interface;  few  connections  and  attachment  points;  rigid,  solid 

structure;  few  sensitive  parts  and  special  precautions  required;  few/small 
deployable  structures  (solar  arrays,  antennas,  etc.);  maximum 
accommodation  of  testing;  few  unique  integration  issues. 


0  Highly  complex  interface;  many  connections  and  attachment  points; 
awkward  structure,  susceptible  to  undesirable  moments,  forces  and 
frequencies;  many  sensitive  parts  and  systems,  requiring  many  special 
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precautions  and  procedures;  awkward  and  inhibiting  deployable  structures; 
testing  the  integrated  system  is  difficult;  several  unique  integration  issues. 


14.4.1.1.4.2  Minimize  Cost  of  Telemetry,  Tracking,  and  Commanding  (TT&C) 

This  cost  covers  all  operational  expenditures  for  tracking,  commanding,  and 
maintaining  the  orbiting  satellite.  Elements  of  TT&C  include  ground  segment  hardware 
and  software,  satellite  operations  personnel,  and  communications  and  data  flow 
operations.  Although  the  evaluation  of  the  most  of  these  elements  is  beyond  the  scope  of 
this  study,  alternative  concepts  will  be  judged  as  to  how  well  they  facilitate  the  TT&C 
function. 

MOE:  Attribute  scale 
Contributing  factors; 

-  On-board  processing 

-  Dedicated  antennas,  number  of  antennas 

-  AFSCN  compatible 

-  Data  down-link 

-  Data  delivery 

5  All  data  processing  can  be  done  on-board;  fully  autonomous;  AFSCN 
compatible;  high  data  rate  transmission  on  separate  band;  user-fnendly, 
simple  but  powerful  system  for  commanding  and  analyzing  telemetry. 

4  Most  of  the  data  processing  can  be  done  on-board;  highly  autonomous; 

AFSCN  compatible;  high  data  rate  transmission  on  separate  band;  user- 
fiiendly,  simple  system  for  commanding  and  telemetry,  with  standard 
analysis  features. 

3  Some  on-board  data  processing;  semi-autonomous;  AFSCN  compatible; 
high  data  rate  transmission  on  separate  band;  user-friendly,  simple  system 
for  commanding  and  telemetry,  with  standard  analysis  features. 

2  Some  on-board  data  processing;  no  autonomy;  AFSCN  compatible; 
standard  command  and  telemetry  system. 

1  No  on-board  data  processing;  no  autonomy;  AFSCN  compatible;  much 
ground  support  required;  standard  command  and  telemetry  system. 
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No  on-board  processing;  no  autonomy;  extensive  ground  support 
required,  with  many  man/computer  hours;  only  compatible  with  a  single, 
dedicated  ground  station  (no  AFSCN  compatibility). 


14.4.1.2  Minimize  Time  to  Full  Rate  Production 

Assuming  that  this  program  will  be  approved  for  further  development  at  each 
program  milestone,  the  time  required  to  achieve  full  rate  production  of  busses  should  be 
minimized. 

MOE:  attribute  scale 
Contributing  factors; 

-  Complexity 

-  Level  of  technology 

-  Availability  of  technology 

-  Challenges  to  manufacturing 

5  All  technology  currently  available  and  on  the  shelf;  no  special  development 
effort  required;  no  long-lead  times  for  parts  and  processes;  no  significant 
advances  in  manufacturing  required. 

4  All  technology  currently  available;  one  or  two  significant  challenges  in 
development;  no  major  manufacturing  advances  required. 

3  Most  technology  currently  available;  a  few  significant  challenges  in 
development;  at  least  one  major  manufacturing  advance  required. 

2  Most  technology  currently  available;  many  significant  challenges  in 
development;  one  or  two  major  manufacturing  advances  required. 

1  Some  technology  currently  available;  many  significant  development 
challenges;  a  few  major  advances  in  manufacturing  required. 

0  Much  technology  under  development  or  unavailable;  most  parts  and 
processes  require  special  development  effort;  several  advances  in 
manufacturing  technology  required. 
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14.4.2  Maximize  Tactical  Responsiveness 

Modsat  is  intended  for  tactical  applications,  as  has  been  stressed  by  the  CDM. 
Thus,  responsiveness  is  a  primary  objective.  Modsat  satellites  must  be  able  to  respond 
quickly  to  rapidly  generated  needs  and  mission  requirements.  One  major  driver  of 
responsiveness  is  the  availability  of  a  launch  vehicle;  however,  it  was  assumed  for  this 
study  that  launch  vehicles  are  continuously  available. 


Max  Tactical 
Responsiveness 


1 


Min  Preparation  I  | 

Min  Data 

1  j  Max  Capability  for 

Time  to  Launch  I  | 

Latency 

1  Tactical  Maneuvers 

Figure  14-3:  Tactical  Responsiveness  Objectives 


14.4.2.1  Minimize  Preparation  Time  to  Launch 

This  time  interval  begins  with  the  demand  for  a  particular  Modsat  mission,  and 
ends  with  the  delivery  of  the  satellite  for  launch  vehicle  integration.  The  phrase  “launch- 
on-need”  has  been  used  throughout  the  study.  It  implies  the  ability  to  launch  within  a  few 
days,  as  opposed  to  several  months. 

MOE:  Attribute  scale 
Contributing  factors: 

-  Number  and  level  of  activities  required  to  integrate  mission  module  to  bus 

and  prepare  satellite  for  launch 

-  Number  of  man-hours  required  to  integrate  mission  module  to  bus  and 

prepare  satellite  for  launch 

-  Number  of  equipment/computer  hours  required 

-  Special  systems  and  processes  required 

-  Safety  hazards 

-  Complexity  of  bus-to-mission  module  interface 
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-  Complexity  of  launch  vehicle-to-payload  interface 

-  Number  and  complexity  of  integrated  system  tests 

Assumptions: 

-  Launch  vehicles  and  launch  sites  are  available  when  the  need  arises 

-  Each  alternative  uses  the  same  manpower  and  facility  scheduling  scheme 

5  Relatively  few  activities  required  to  integrate  the  mission  module  to  the 
bus,  and  to  prepare  the  satellite  for  launch;  process  is  not  man-hour  or 
equipment-hour  intensive;  few  special  systems  and  processes  required; 
relatively  few  significant  safety  hazards  exist;  simple  interfaces;  only  a  few, 
simple  tests  required  on  the  integrated  systems. 


0  Many  difficult  activities  required  to  integrate  the  mission  module  to  the 

bus,  and  to  prepare  the  satellite  for  launch;  process  is  highly  man-hour  and 
equipment-hour  intensive;  many  special  systems  and  processes  required; 
many  significant  safety  hazards  exist;  highly  complex  interfaces;  many 
challenging  tests  required  on  the  integrated  systems. 


14.4.2.2  Minimize  Data  Latency 

Data  latency  refers  to  the  time  between  mission  data  collection  and  reception  by 
the  user  in  raw  form.  This  objective  should  capture  the  differences  in  data  processing  and 
data  down-linking  architectures. 

MOE:  Attribute  scale 
Contributing  factors: 

-  Down-link  rate. 

-  On-board  data  processing  capability. 

-  Data  delivery  architecture. 

5  Very  fast  turnaround-time  fi'om  data  collection  to  data  reception  in  useable 
form;  highly  flexible  and  capable  data  delivery  architecture,  compatible 
with  AFSCN,  dedicated  and  portable  stations;  very  high  data  down-link 
rate. 


116 


4  Fast  turnaround-time  from  data  collection  to  useable  reception;  highly 

capable  and  somewhat  flexible  data  delivery  architecture;  very  high  data 
down-link  rate. 

3  Moderate  turnaround-time  from  data  collection  to  useable  reception;  highly 
capable  but  inflexible  data  delivery  architecture;  high  data  down-link  rate. 

2  Moderate  turnaround-time  from  data  collection  to  useable  reception; 

moderately  capable,  inflexible  data  delivery  architecture;  moderate  down¬ 
link  rate. 

1  Slow  turnaround-time  from  data  collection  to  useable  reception;  low- 

capability,  inflexible  data  delivery  architecture;  moderate  to  low  down-link 
rate. 

0  Very  slow  turnaround-time  from  data  collection  to  useable  reception;  very 
low-capability,  highly  inflexible  data  deliveiy  architecture;  low  to  very  low 
down-link  rate. 


14.4.2.3  Maximize  Capability  For  Tactical  Maneuvers 

The  satellite  may  be  called  on  to  perform  plane  changes  or  slewing  maneuvers  in 
response  to  tactical  mission  needs.  This  sub-objective  covers  both  slewing  capability  and 
AV  (change  in  velocity)  capability,  which  depend  on  how  much  extra  fuel  is  loaded 
beyond  that  required  for  normal  usage.  AV  is  a  more  usefiil  measure  than  the  mass  of 
extra  fuel,  since  AV  performance  is  proportional  to  specific  impulse,  which  can  be 
different  for  different  fuels  and  propulsion  systems  of  the  same  weight. 

MOE:  Attribute  scale 
Contributing  factors: 

-  Slew  rate 

-  Amount  of  delta-V  (fuel)  available  for  plane  changes 

Note:  The  output  torque  capability  of  the  reaction  wheels  is  a  proxy 

measure  for  the  achievable  slew  rate.  The  available  delta-v  for  plane 
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changes  is  found  by  subtracting  from  the  total  delta-v  supply  the  amount 
needed  for  altitude  maintenance  and  momentum  dumping. 

5  Very  fast  slew  rate;  two-degree  plane  change  allowed. 

4  Fast  slew  rate;  1.5-degree  plane  change  allowed. 

3  Moderate  slew  rate;  one-degree  plane  change  allowed. 

2  Moderate  slew  rate;  0.5-degree  plane  change  allowed. 

1  Slow  slew  rate;  0.5-degree  plane  change  allowed. 

0  Very  slow  slew  rate;  no  capability  for  plane  changes. 

14.4.3  Maximize  Availability 

A  sound  system  design  for  Modsat  must  attempt  to  maximize  on-orbit  availability. 
The  bus  must  endure  both  natural  and  man-made  hazards.  Natural  hazards  are  considered 
under  reliability,  while  man-made  hazards  are  considered  under  survivability. 


Figure  14-4:  Availability  Objectives 


14.4.3.1  Maximize  Reliability 


For  the  purposes  of  this  study,  reliability  refers  to  the  probability  that,  given  a  non- 
hostile  environment,  the  bus  will  be  able  to  perform  its  primary  mission  of  supporting  the 
mission  module  at  a  given  point  in  its  lifetime.  It  is  partly  a  measure  of  the  hardness  of  the 
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bus  to  the  natural  space  environment  over  the  satellite’s  lifetime,  within  a  specified 
confidence  level.  Since  the  maximum  lifetime  requested  by  the  CDM  was  one  year,  this 
objective  was  as  evaluated  as  the  reliability  at  one  year.  But  high  reliability  beyond  the 
one  year  point  has  value,  in  that  more  use  could  be  made  of  a  given  Modsat  satellite.  If  it 
could  be  shown  that  Modsat  could  achieve  high  reliability  at  two  or  even  three  years,  with 
little  impact  on  cost,  this  would  greatly  interest  the  CDM. 

MOE:  Overall  system  reliability  at  one  year,  R(one  year). 


14.4.3.2  Maximize  Survivability 

SurvivabiUty  refers  to  the  ability  of  the  system  to  perform  its  intended  mission  after 
exposure  to  stressing  environments  created  by  enemy  or  hostile  agent. 

MOE:  Attribute  scale 
Contributing  factors; 

-  “Safe”  modes  of  operation 

-  Ability  for  evasive  maneuvers 

-  Shielding  from  radiation  and  EMP 

-  Protection  of  circuitry  and  computer  memory 

5  Auto  safe  mode;  full  array  of  evasive  maneuvers  available;  structure  and 

components  have  maximum  shielding  against  radiation  and  EMP;  extensive 
protection  of  circuitry  and  computer  memory. 

4  Remote  safe  mode;  limited  evasive  maneuvers;  structure  and  components 
have  moderate  level  of  shielding;  extensive  protection  of  circuitry  and 
computer  memory. 

3  Remote  safe  mode;  limited  evasive  maneuvers;  structure  and  components 
have  moderate  level  of  shielding;  limited  protection  of  circuitry  and 
computer  memory. 
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2  Limited  remote  safing  actions;  no  evasive  maneuvers;  limited 

shielding  of  structure  and  components;  limited  protection  of  circuitry  and 
computer  memory. 

1  No  safe  mode;  no  evasive  maneuvers;  no  shielding  of  structure  and 
components;  limited  protection  of  circuitry  and  computer  memory. 

0  No  safe  mode;  no  evasive  maneuvers;  no  shielding  of  structure  and 
components;  no  protection  of  circuitry  and  computer  memory. 

14.4.4  Minimize  Program  Risk 

Program  risk  refers  to  the  potential  for  elements  of  the  program  to  fail  to  come 
together  as  planned.  Risk  can  be  assessed  in  the  areas  of  cost,  schedule,  and  performance. 
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Figure  14-5:  Program  Risk  Objectives 
14.4.4.1  Minimize  Cost  Risk 

Each  system  development  program  has  cost  risk,  in  that  the  predicted  life  cycle 
costs  or  individual  elements  of  the  cost  may  be  much  higher  than  planned.  In  a  sense,  cost 
risk  is  a  measure  of  the  lack  of  confidence  in  the  cost  estimates.  An  accurate  and 
dependable  cost  model  helps  to  lower  cost  risk. 

Note  the  difference  between  cost  risk  and  cost.  An  alternative  solution  that  has  a 
high  cost  but  for  which  there  is  a  great  deal  of  confidence  in  the  cost  estimate  would  have 
low  cost  risk.  Likewise,  an  alternative  that  has  a  low  cost  but  for  which  there  is  low 
confidence  in  the  cost  estimate  would  have  high  cost  risk. 
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MOE:  Attribute  scale 


Contributing  factors: 

-  Uncertainty  in  cost  estimates 

-  Unique  systems,  parts,  and  procedures 

5  Exact  knowledge  of  cost  of  all  facets  of  bus  recurring  and  non-recurring 
costs. 

4  Knowledge  of  costs  for  many  aspects  of  the  program;  all  systems,  parts, 

and  processes  have  much  historical  cost  data;  CERs  are  well-suited  to 
estimate  costs  for  all  areas  where  exact  knowledge  doesn’t  exist. 

3  All  systems,  parts,  and  processes  have  much  historical  data;  CERs  are  well- 
suited  to  estimate  costs  for  most  areas;  some  proxy  measures  instead  of 
CERs. 

2  Most  systems,  parts,  and  processes  have  historical  data;  most  CERs  are 
well-suited  to  estimate  costs;  some  uncertainty  in  estimates;  some  proxy 
measures  used  instead  of  CERs. 

1  Few  systems,  parts,  and  processes  have  historical  data;  most  CERs  are  not 
well-suited  to  estimate  costs;  many  proxy  measures  used  instead  of  CERs; 
much  uncertainty  in  estimates. 

0  Total  uncertainty  in  cost  estimates;  CERs  are  not- well  suited;  most 
systems,  parts  and  processes  do  not  have  historical  data;  almost  all 
objectives  must  be  measured  with  proxy  measures. 


14.4.4.2  Minimize  Schedule  Risk 

Schedule  risk  refers  to  the  potential  for  unforeseen  slips  in  the  development 
schedule.  Schedule  risk  can  be  mitigated  with  sensible  planning  and  accurate  forecasting. 
MOE;  Attribute  scale 
Contributing  factors: 

-  Unique,  exotic  equipment  and  processes  required  in  manufacturing,  test, 
integration,  and  support 

-  Amount  and  level  of  unproved  technology  used  on  the  bus 

-  Difficulty  of  program  planning  and  prediction 
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-  Potential  for  tricky  integration  issues,  both  for  the  mission  module  and  the 
launch  vehicle 

5  Few  unique  systems  and  processes  required  in  manufacturing,  test, 

integration,  and  support;  all  technology  is  flight-qualified  and  well-proven; 
no  major  foreseen  diflSculties  in  program  planning  and  prediction;  no  major 
foreseen  tricky  integration  issues. 


0  Most  systems  and  processes  for  manufacturing,  test,  integration,  and 

support  are  highly  unique;  much  unproved,  cutting-edge  technology;  several  major 
foreseen  difficulties  in  program  planning  and  prediction;  several  major  foreseen 
tricky  integration  issues. 


14.4.4.3  Minimize  Performance  Risk 

There  is  a  chance  that  some  technological  aspect  of  the  system,  be  it  hardware  or 
software,  will  not  work  as  well  as  planned.  This  usually  depends  on  the  maturity  of  the 
technology  in  question. 

MOE;  Attribute  scale 
Contributing  factors: 

-  Amount  and  level  of  unproved  technology  used  on  the  bus 

-  Amount  and  level  of  testing 

5  Almost  no  cutting-edge  technology;  all  hardware  and  software  is  flight- 
qualified  and  well-proven;  extensive  test  program. 


0  Much  cutting-edge  technology;  very  little  flight-qualified  hardware  and 
software;  very  little  testing  achieved  or  even  possible. 
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14.4.5  Maximize  Mission  Utility 


Mission  utility  refers  to  the  ability  of  Modsat  to  accommodate  a  range  of  different 
mission  modules.  In  other  words,  it  is  a  way  of  quantifying  how  well  the  bus  performs  its 
role  of  being  generic  and  standard.  The  larger  the  range  of  possible  missions,  the  higher 
the  mission  utility.  This  objective  was  difficult  to  construct,  since  it  is  hard  to  envision 
how  such  utility  can  be  measured.  It  was  decided  that  mission  utility  is  supported  by 
various  aspects  of  spacecraft  bus  performance  such  as  pointing  accuracy  and  available 
power.  In  other  words,  if  more  performance  capability  is  built  into  the  bus,  more  mission 
types  can  be  accommodated.  Thus,  several  performance  sub-objectives  were  adopted,  in 
addition  to  the  obvious  desire  to  maximize  the  available  weight  and  volume  for  the  mission 
module. 


Figure  14-6;  Mission  Utility  Objectives 


14.4.5.1  Maximize  Pointing  Accuracy 


Many  space  mission  applications  require  a  great  deal  of  spacecraft  pointing 
accuracy,  for  precise  pointing  and  orientation  of  sensing  instruments. 
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MOE:  Degrees  of  pointing  accuracy  (smaller  values  are  desired) 


14.4.5.2  Maximize  Orbital  Accuracy 

The  satellite  must  be  able  to  maintain  its  intended  orbit,  in  order  to  be  available  for 
its  intended  applications. 

MOE;  Attribute  scale 
Contributing  factors: 

-  Whether  or  not  there  is  a  propulsion  system  on-board 

-  Amount  of  fiiel,  in  terms  of  delta-v,  reserved  for  maintaining  orbital 
altitude 

5  Enough  propellant  to  maintain  the  full  orbital  altitude  for  the  design  life  of 
the  satellite. 


0  No  propellant  reserved  for  orbital  maintenance. 


14.4.5.3  Maximize  Data  Storage 

Various  missions  may  require  the  spacecraft  processor  to  temporarily  store  mission 
data  for  later  transmission. 

MOE:  Attribute  scale 
Contributing  factors: 

-  Size  of  data  recorder  (gigabits  of  storage) 

-  Capability  of  data  recorder  (compression,  etc.) 

-  Rate  of  data  collection 

-  Frequency  of  data  transmission 

5  Very  large,  highly  capable  device;  maximum  compression;  handles  toughest 
scenario  of  high  rate  of  collection  but  low  frequency  of  transmission;  can 
store  high  resolution  data  of  several  orbits. 
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4  Large,  very  capable  device;  high  compression;  handles  high  rate  of 
collection  and  moderate  frequency  of  transmission;  can  store  high 
resolution  data  of  more  than  one  orbit. 


1  Small  recorder  with  minimum  capability;  no  compression;  handles  only  low 
rate  of  collection  and  data  must  be  transmitted  quickly;  stores  low 
resolution  data  of  a  short  pass  within  an  orbit. 

0  No  flight  data  recorder  on-board;  zero  capability  for  data  storage. 

14.4.5.4  Maximize  Data  Down-link  Rate 

Although  Modsat  must  be  compatible  with  the  Air  Force  Satellite  Control 
Network  (AFSCN),  some  missions  may  require  a  higher  data  down-link  rate  than  can  be 
accommodated  with  AFSCN  compatible  communications  equipment.  Systems  solutions 
that  provide  for  higher  rates  would  be  more  attractive,  all  other  factors  being  equal. 
MOE:  Mbytes/sec 

14.4.5.5  Maximize  Average  Mission  Module  Power 

This  objective  strives  to  maximize  the  amount  of  power,  on  average,  that  Modsat 
makes  available  to  the  mission  module.  A  survey  of  existing  LEO  military  satellites 
reveals  that  their  power  requirements  cover  a  wide  range. 

MOE:  Watts  of  available  average  power 

Note:  Available  average  power  is  the  total  average  power  minus  the  total  power 
required  by  the  bus. 
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14.4.5.6  Maximize  Peak  Mission  Module  Power 


Some  mission  applications  will  require  large  amounts  of  power  during  peak 
operations.  Modsat  must  be  able  to  handle  peak  demands  which  can  greatly  exceed  the 
average  demand. 

MOE:  Watts  of  available  peak  power 

Note;  Available  peak  power  is  the  total  peak  power  minus  the  total  power 
required  by  the  bus. 

14.4.5.7  Maximize  Allowable  Mission  Module  Weight 

One  of  the  main  design  goals  of  this  study  is  a  lightweight  bus  which  allows  for  the 
heaviest  possible  mission  module.  The  amount  of  allowable  mission  module  weight  is 
determined  by  subtracting  the  bus  weight  from  the  total  allowable  weight,  which  depends 
on  the  launch  vehicle  and  the  selected  orbit. 

MOE:  Kilograms  of  available  weight 

Note:  Allowable  mission  module  weight  is  defined  as  the  weight  that  can  be  launched  to 
the  specified  orbit  minus  the  total  wet  weight  of  the  bus. 

14.4.5.8  Maximize  Allowable  Mission  Module  Volume 

This  sub-objective  is  met  by  minimizing  the  volume  of  the  bus.  The  amount  of 
allowable  mission  module  volume  is  determined  by  subtracting  the  bus  volume  from  the 
total  allowable  volume,  which  depends  on  the  volume  and  dimensions  of  the  launch 
vehicle  payload  fairing. 

MOE:  cm^  of  available  volume 

Note:  Allowable  mission  module  volume  is  defined  as  the  usable  volume  of  the  launch 
vehicle  minus  the  total  volume  of  the  bus. 
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14.4.5.9  Maximize  Adaptability 

This  sub-objective  should  capture  the  CDM’s  desire  for  flexibility  of  design  and 
adaptability  to  changing  mission  requirements.  The  ability  to  add  needed  capability  or 
remove  excess  capability  is  valued,  while  at  the  same  time  consideration  must  be  given  to 
minimizing  the  amount  of  engineering  which  must  be  applied  to  the  integration  effort. 
Alternative  solutions  will  be  judged  on  how  well  they  meet  this  goal. 

MOE:  Attribute  scale 
Contributing  factors; 

-  Degree  of  modularity  and  flexibility  in  the  bus 

-  Ability  to  insert  more  capability  or  remove  excess  capability 

-  Breadth  of  mission  profile  capability 

-  Ease  of  updating  subsystems  and  components  with  technological 
upgrades,  without  a  major  system  redesign 

5  Supports  a  wide  breadth  of  mission  profiles;  highly  flexible  design  with 

near  total  modularity;  nearly  all  subsystems  can  be  easily  replaced  with  new 
versions;  additional  capability  can  easily  be  inserted;  excess  capability  can 
easily  be  removed. 

4  Supports  several  different  mission  profiles;  flexible  design  with  much 
modularity;  many  subsystems  can  easily  be  replaced  with  new  versions; 
some  additional  capability  can  be  inserted;  some  excess  capability  can  be 
removed,  but  not  all. 

3  Supports  several  different  mission  modules  \vith  a  few  different  mission 
profiles;  moderate  amount  of  modularity  and  flexibility;  a  few 
subsystems/components  can  be  replaced  without  major  redesign;  some 
excess  capability  can  be  removed;  limited  ability  to  add  additional 
capability. 

2  Supports  a  few  different  mission  modules  with  one  or  two  different  mission 
profiles;  limited  modularity  and  flexibility;  only  one  or  two  subsystems/ 
components  can  be  replaced  without  major  redesign;  limited  ability  to 
remove/add  capability. 

1  Supports  only  similar  mission  modules  with  the  same  mission  profile; 
limited  modularity  or  flexibility;  fked  design,  with  almost  all  component 
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upgrades  requiring  a  major  system  redesign;  most  components  are  fixed  in 
structure,  with  limited  capability  for  removal  or  replacement;  does  not 
support  additional  capabilities. 

0  Supports  only  a  single  baseline  mission  module;  virtually  no  modularity  or 
flexibility;  fixed  design,  with  almost  all  component  upgrades  requiring  a 
major  system  redesign;  all  components  are  fixed  in  the  structure,  with  no 
capability  for  removal  or  replacement;  does  not  support  additional 
capabilities. 

14.4.5.10  Minimize  Thermal  Transfer 

It  is  necessary  to  limit  the  amount  of  heat  energy  that  passes  between  subsystems 
and  components,  as  well  as  from  the  bus  to  the  mission  module.  Many  components  on  a 
spacecraft  can  be  very  sensitive  to  heat.  Consideration  must  be  given  to  the  highly 
dynamic  nature  of  a  spacecraft  thermal  environment. 

MOE:  Attribute  scale 
Contributing  factors: 

-  Amount  of  heat  energy  crossing  the  interface  between  bus  and  mission 
module 

-  Quality  of  thermal  management  within  the  bus 

5  Virtually  no  heat  energy  crosses  the  interface;  excellent  thermal 
management  on  the  bus. 


0  Much  heat  energy  crosses  the  interface;  poor  thermal  management  on  the 
bus. 


14.5  Utility  Functions 

In  order  to  provide  overall  utility  scores  for  each  competing  system  solution,  all 
MOEs  must  be  converted  to  a  common  utility  scale.  A  utility  scale  from  zero  to  one  was 
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chosen  for  convenience,  but  the  endpoints  of  the  scale  could  be  any  numbers.  The 
translation  from  MOE  to  utility  for  a  given  objective  is  referred  to  as  the  utility  function  of 
that  objective.  A  utility  function  is  essentially  a  model  that  represents  the  preferences  of 
the  CDM  for  an  objective  (Clemen,  1996:473).  According  to  Clemen,  “assessing  a  utihty 
fimction  is  a  matter  of  subjective  judgment”  (Clemen,  1996:473).  Feedback  from  the 
CDM  enables  the  analyst  to  determine  how  much  utility  to  assign  a  given  level  of 
performance. 

14.5.1  Theory 

Figure  14-7  shows  the  three  basic  shapes  of  utility  functions  (Clemen,  1996:466). 
Often,  a  higher  level  of  performance,  or  payoff,  is  associated  with  greater  risk.  In  other 
words,  the  price  of  trying  to  achieve  higher  performance  is  a  greater  probability  of  a 
failure  or  loss  of  some  kind.  For  example,  a  gambler  may  have  to  accept  a  greater  risk  of 
losing  money  if  he  wants  a  chance  to  win  a  big  payoff. 

An  individual  with  risk-averse  behavior  will  accept  a  lower  payoff  in  return  for  less 
risk  of  loss.  For  this  individual,  there  is  a  diminishing  return  on  increases  in  the  level  of 
performance.  Thus,  a  risk-averse  utility  curve  is  concave  (Clemen,  1996:465).  The  CDM 
may  be  risk-averse  (diminishing  return  on  performance)  with  regard  to  several  of  the 
objectives.  For  other  objectives,  the  CDM  may  feel  that  maximizing  performance  is  the 
same  as  maximizing  utility,  so  that  a  linear  translation  of  payoff  to  utility  is  appropriate. 
This  is  knovra  as  a  risk-neutral  utility  function,  and  the  corresponding  utility  curve  is  a 
straight  line  (Clemen,  1996:466).  It  is  possible  that  the  CDM  may  be  risk-seeking  with 
regard  to  an  objective.  A  risk-seeker  will  look  for  a  high  payoff,  regardless  of  the  risk. 

The  corresponding  utility  curve  is  convex  (Clemen,  1996:465). 
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Figure  14-7:  Basic  Utility  Functions 


14.5.2  Application 

Ideally,  each  objective  would  have  a  unique  utility  function  that  reflects  the  risk 
attitude  of  the  CDM.  However,  in  the  absence  of  participation  from  the  CDM,  the  team 
took  a  generalized  approach.  It  was  felt  that  the  main  objective  areas  of  cost  and  risk 
should  have  risk-averse  utility  functions,  with  the  exception  of  RDT&E  and  production 
costs  (discussed  below),  while  the  main  areas  of  tactical  responsiveness,  availability,  and 
utility  should  have  risk-neutral  utility  functions.  This  was  a  subjective  judgment,  based  on 
the  combined  experience  and  knowledge  of  the  team  members.  The  validity  of  the  results 
of  this  study  could  be  improved  with  feedback  from  the  CDM  with  regard  to  utility 
functions. 

All  of  the  objectives  with  risk-averse  utility  functions  have  attribute  scales  from 
zero  to  five.  To  be  conservative,  the  team  chose  a  slightly  concave  curve,  with  a 
translation  as  shown  in  Table  14-1. 


130 


Table  14-1:  Risk-averse  Utility  Conversion 


Performance 

0 

1 

2 

3 

4 

5 

isssniH 

0.00 

0.30 

0.55 

0.75 

0.90 

1.00 

The  corresponding  utility  curve  is  shown  in  Figure  14-8.  During  the  analysis  phase  of  this 
study,  non-integer  values  of  performance  were  translated  using  a  curve-fitting  function. 

1 

0.5 
D 

0 

0  1  2  3  4  5 

Performance 

Figure  14-8:  Risk-averse  Utility  Curve 

All  risk-neutral  objectives  have  linear  translations  from  performance  levels  to 
utilities.  For  those  objectives  with  attribute  scales  as  MOEs,  the  utility  is  found  by 
dividing  the  performance  level  by  five.  All  objectives  in  this  study  that  have  natural  MOEs 
are  risk-neutral.  For  the  sake  of  simplicity,  RDT&E  and  production  costs  were  included 
in  this  group. 

The  assignment  of  utilities  for  natural  MOEs  is  somewhat  more  difficult  than  for 
attribute  scales.  The  analyst  must  decide  what  level  of  performance  receives  a  perfect 
utility  score  of  one,  and  what  level  receives  the  worst  score  of  zero.  Two  approaches  are 
possible.  On  one  hand,  the  analyst  can  determine  the  absolute  best  and  worst  values  that 
could  be  achieved  within  the  context  of  the  problem.  This  approach  relies  on  the 
knowledge  of  subject  matter  experts  who  are  familiar  with  the  problem,  and  requires  much 
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research  on  the  part  of  the  analyst.  On  the  other  hand,  the  analyst  can  wait  to  assign 
utilities  until  the  performance  values  of  all  the  alternative  solutions  have  been  recorded.  In 
this  scheme,  the  best  value  receives  a  utility  of  one,  the  worst  value  receives  a  utility  of 
zero,  and  all  values  in-between  are  proportionally  scored  between  zero  and  one.  Given 
the  time  constraint  and  lack  of  space  design  experience  on  the  team,  the  latter  approach 
was  chosen. 

14.6  Priority  Weighting  of  The  Objectives 

As  in  phase  one  of  the  study,  objectives  on  the  same  level  in  the  hierarchy  were 
assigned  priority  weights,  as  shown  in  Figure  14-9.  These  weights  were  determined  in  the 
same  manner  as  in  phase  one,  based  on  the  results  of  a  preference  chart  survey.  This 
survey  was  completed  by  the  CDM,  members  of  the  team,  and  other  subject  matter 
experts,  with  feedback  from  the  CDM  being  more  heavily  weighted.  The  actual  survey  is 
attached  as  Appendix  A. 
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personal  opinions,  solicited  at  a  certain  time  and  under  a  given  set  of  technological, 
political,  and  economic  conditions.  Major  changes  in  any  of  these  areas  could  cause  the 
relative  priorities  to  change.  This  potential  for  change  does  not  present  a  significant 
problem,  since  the  overall  scoring  function  (see  section  14.7)  can  easily  be  re-calculated 
with  new  weights.  In  fact,  a  sensitivity  analysis  was  performed  on  the  alternative 
solutions  by  varying  the  weights  of  each  of  the  top-level  objectives.  See  ‘T)ecision 
Making”  for  the  results  of  this  analysis. 

A  comparison  of  the  priorities  of  the  top-level  objectives  is  shown  in  Figure  14-10. 
Tactical  responsiveness  is  the  highest-rated  objective,  while  mission  utility  has  the  second 
highest  priority.  It  is  interesting  to  note  that  the  cost  objective  received  the  lowest  rating, 
as  opposed  to  its  prominence  in  most  system  studies. 

Figure  14-9  shows  that  the  minimization  of  dollar  cost  is  far  more  important  than 
the  minimization  of  the  time  to  full  rate  production.  Within  the  dollar  cost  objective, 
retirement  cost  has  the  highest  priority,  while  operations  cost  has  the  lowest  priority. 
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Figure  14-10:  Top-level  Objective  Weights 


The  distribution  of  priorities  for  the  tactical  responsiveness  objective  is  shown  in 
Figure  14-1 1 .  The  minimization  of  data  latency  has  the  highest  priority.  This  is  consistent 
with  the  recent  emphasis  of  the  military  on  combat  theater  information  flow.  As 
warfighters  grow  more  and  more  dependent  on  satellite  data,  it  is  crucial  that  they  receive 
satellite  data  as  quickly  as  possible,  with  real-time  data  being  the  ideal  standard.  The 
weight  of  this  objective  demonstrates  the  importance  of  minimizing  the  time  required  to 
store,  process,  and  down-link  satellite  data. 
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Figure  14-11:  Tactical  Responsiveness  Weights 

Figure  14-9  shows  that  reliability  is  the  more  important  aspect  of  availability,  while 
performance  risk  has  the  highest  priority  among  the  program  risk  objectives. 

Figure  14-12  shows  the  weights  of  the  ten  sub-objectives  under  the  mission  utility 
objective.  The  minimization  of  pointing  accuracy  is  the  most  important  sub-objective, 
followed  by  the  maximization  of  allowable  mission  module  weight.  Maximization  of  peak 
mission  module  power  is  the  least  important  sub-objective. 
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Objectives 


Figure  14-12:  Mission  Utility  Weights 

14.7  Scoring  Function 

The  utility  values  and  objective  weights  must  be  combined  to  form  an  overall 
utility  function.  This  function  yields  an  overall  utility  score  for  a  given  alternative 
solution,  based  on  its  performance  of  each  objective  and  the  relative  importance  of  those 
objectives.  Alternative  systems  solutions  can  be  compared  by  their  overall  utility  scores. 
The  utility  function  used  for  this  study  was  additive,  such  that 

U  =  kp,+k,U,+...+kJJ„ 

where  U  is  the  overall  utility,  Ui,  U2, ...  U™  are  the  individual  utility  functions  for  the  m 
objectives,  and  ki,  k2, ...  k^  are  the  weights  for  each  objective  (Clemen,  1996:537).  The 


use  of  an  additive  utility  function  must  be  justified,  since  it  ignores  any  interaction  among 


the  attributes.  For  instance,  some  attributes  may  be  complementary  in  nature,  such  that 

high  achievement  on  all  of  them  leads  to  more  success  than  the  sum  of  the  individual 

successes  (Clemen,  1996:576).  In  order  to  achieve  accurate  results  with  an  additive  utility 

function,  additive  independence  must  hold.  Additive  independence  requires  that  the 

weights  for  the  objectives  at  a  given  level  in  a  branch  of  the  hierarchy  add  up  to  one. 

According  to  Clemen,  “When  we  are  considering  a  choice  among  risky  prospects 

involving  multiple  attributes,  if  additive  independence  holds,  then  we  can  compare  the 

alternatives  one  attribute  at  a  time”  (Clemen,  1996:584). 

Since  this  study  was  intended  to  produce  concept-exploration  design 

characteristics,  and  not  detailed  design  recommendations,  the  team  decided  to  avoid 

modeling  the  interaction  among  the  objective  attributes.  According  to  Clemen, 

...  in  extremely  complicated  situations  with  many  attributes,  the  additive 
model  may  be  a  useful  rough-cut  approximation.  It  may  turn  out  that 
considering  the  interactions  among  attributes  is  not  critical  to  the  decision 
at  hand  (Clemen,  1996:585). 

Based  on  this  reasoning,  the  additive  utility  function  was  deemed  appropriate  for  this 
study. 


138 


14.8  FlexibUity  of  the  Value  System 


Since  the  value  system  drives  all  design  efiforts,  changes  in  any  of  the  elements  of 
the  value  system  can  lead  to  different  results.  The  objectives,  weights,  and  utility 
functions  used  for  this  study  could  be  modified  upon  further  engineering  efforts.  It  was 
not  the  intent  of  the  team  to  create  a  rigid,  unchanging  value  structure,  but  rather  to  create 
a  robust  fi'amework  within  which  intelligent  decisions  could  be  made.  Now  that  the 
framework  exists,  it  can  be  modified  according  to  the  changing  desires  of  the  CDM  and 
the  analysts  who  conduct  further  research  on  this  topic. 
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15.  Tradeoffs 


15.1  System  Level 

Many  important  tradeoffs  were  analyzed  at  the  system  and  subsystem  level,  and 
several  critical  design  decisions  were  made.  The  purpose  of  this  section  of  the  report  is  to 
document  these  tradeoffs  and  decisions.  Throughout  the  system  study,  the  team  has 
encountered  many  variables  and  options.  Some  of  these  have  remained  as  variables,  to  be 
specified  as  elements  of  alternative  system  solutions  for  judgment  against  the  value  system 
criteria.  However,  many  design  decisions  were  made  during  this  study,  in  order  to  narrow 
the  solution  space  to  a  reasonable  set  of  alternatives.  Thus,  the  Modsat  bus  concept 
gained  its  shape  throughout  the  study,  as  key  decisions  have  built  on  each  other.  These 
decisions  were  made  after  performing  tradeoffs  between  the  alternatives,  judging  each 
against  the  Modsat  objectives  and  constraints. 

Much  work  was  done  at  the  subsystem  level,  and  this  is  documented  in  section 
15.5.  This  section  discusses  the  system  level  tradeoffs. 

15.1.1  One  Satellite  Per  Launch  Vehicle 

Rather  than  attempt  to  design  very  small  satellite  busses  for  a  multiple-payload 
launch  package,  the  team  chose  to  focus  on  one  vehicle  that  will  fill  the  payload  bay  of  the 
chosen  launch  vehicle  (LV).  A  key  objective  of  the  study  is  to  allow  for  as  much  mission 
module  capability  as  possible  per  bus.  It  would  be  inconsistent  with  this  objective  to  force 


140 


mission  module  designers  to  integrate  with  a  microsat,  or  to  make  them  spread  their 
mission  capability  over  a  multiple-satellite  configuration. 

15.1.2  Launch  Vehicle 

The  team  originally  chose  the  Pegasus  XL,  from  Orbital  Sciences  Corporation 
(OSC),  for  reasons  which  are  discussed  in  full  in  section  15.3.  This  LV  is  common  for 
small  low  earth  orbit  (LEO)  satellites.  It  is  attractive  for  several  reasons,  among  them 
being  the  ability  to  respond  rapidly  to  mission  needs  and  the  flexibility  of  launch 
integration  and  location. 


15.1.3  Basic  Spacecraft  Configuration 

The  basic  configuration  of  a  spacecraft  depends  on  its  primary  means  of  attitude 

stabilization.  Most  LEO  spacecraft  are  either  two-axis  stabilized  via  spinning  the  body,  or 

three-axis  stabilized  via  an  internal  device  to  control  attitude. 

Modsat  requires  three  axes  of  pointing  control,  since  it  has  articulated  solar  arrays 

(see  section  15.5.6.4)  and  must  accommodate  nadir  pointing  mission  modules.  According 

to  aerospace  consultant  Emery  Reeves, 

“The  spacecraft  configuration  must  provide  two  axes  of  control  for  each 
item  that  is  to  be  pointed.  The  spacecraft  body  has  three  axes  so  the  body 
alone  can  satisfy  one  pointing  requirement;  for  instance,  one  body  axis  (i.e., 
the  yaw  axis)  can  be  pointed  toward  nadir  by  control  about  the  other  two 
axes  (roll  and  pitch).  It  two  items  are  to  be  pointed,  then  the  spacecraft 
must  be  configured  with  at  least  one  articulated  joint  between  the  two 
items.  For  illustration,  a  body  mounted  antenna  can  be  pointed  nadir  by 
controlling  two  axes  of  body  attitude.  A  solar  array  can  then 
simultaneously  be  pointed  toward  the  Sun  by  using  the  third  body  axis  and 
providing  a  single  solar  array  drive  to  control  the  solar  array  attitude 
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relative  to  the  body. .  .3-axis-controlled  spacecraft  generally  use  articulated 
panels”  (Reeves,  1992:297). 

Although  two-axis  systems  are  usually  cheaper,  lighter,  and  less  complex  than 
three-axis  systems  (Reeves,  1992:305),  it  was  determined  that  the  pointing  requirements 
of  both  the  solar  arrays  and  the  nadir  pointing  mission  modules  mandate  the  use  of  three- 
axis  control.  In  the  discussion  on  mission  module  requirements,  it  was  stated  that  Modsat 
must  provide  pointing  control  at  least  as  accurate  as  0.1  degrees.  According  to  Reeves, 
high  accuracy  pointing  (<0.1  deg)  implies  the  need  for  three-axis  control. 

The  team  also  decided  to  use  active  control,  with  propulsion  thrusters  and  reaction 
wheels  (see  section  15.5.1  and  section  15.5.2).  According  to  Reeves,  “The  active  three- 
axis  method  gives  us  highly  accurate  pointing  control,  more  efficient  solar  arrays  (by 
alloAving  oriented  planar  arrays),  and  pointing  of  several  payloads  or  spacecraft 
appendages”  (Reeves,  1992:304). 

15.1.4  Data  Delivery  Architecture 

The  users  in  the  field  would  like  to  have  their  mission  data  as  rapidly  as 
possible.  By  requirement,  Modsat  must  have  S-band  SGLS  (space  to  ground-link 
subsystem)  antennas  which  are  compatible  with  the  AFSCN.  The  SGLS  link  is  limited  to 
a  maximum  data  rate  of  1 .024  Mbits/sec.  Any  tactical,  warfighting  satellite  would  benefit 
greatly  from  having  its  own  high  data  rate  downlink  antenna(s),  in  addition  to  the  SGLS 
antennas.  Thus,  the  design  team  acknowledged  that  almost  all  Modsat  satellites  would 
require  a  high  data  rate  antenna  in  addition  to  the  required  SGLS  antennas.  It  was 
decided  by  the  team  to  avoid  selecting  and  integrating  a  particular  type  of  antenna. 
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Rather,  the  mission  planners  will  have  the  flexibility  to  choose  antennas  that  suit  their 
needs.  Thus,  all  Modsat  bus  designs  accounted  for  the  placement  of  a  high  data  rate 
package,  whether  in  the  bus  itself  (as  a  standardized  add-on)  or  as  part  of  the  mission 
module. 


15.1.5  Adaptability  and  Modularity 

As  mentioned  in  the  Problem  Definition  section,  the  CDM  desires  Modsat  to  have 
a  flexible,  adaptable  design,  such  that  additional  capability  can  inserted,  or  excess 
capability  can  be  removed,  depending  on  the  needs  of  each  mission  module.  There  have 
been  other  programs  with  similar  design  goals.  One  such  program  was  the  Advanced 
Technology  Standardized  Satellite  Bus  (ATSSB),  under  the  direction  of  ARP  A.  An 
interview  was  conducted  with  the  former  director  of  the  ATSSB  program.  Colonel 
(Retired)  Ed  Nicastri.  Mr.  Nicastri  explained  that  his  program  examined  this  issue  of  the 
adaptable  configuration.  They  chose  a  modular  approach,  whereby  components  are 
plugged  in  to  the  bus  like  circuit  cards,  and  removed  when  not  needed. 

Nicastri  advised  that  it  is  far  better  to  design  in  a  high  degree  of  capability,  and 
remove  the  excess,  than  to  start  with  the  minimum  and  add  as  necessary.  The  latter 
approach  implies  a  skeletal  structure,  where  components  are  attached  as  required  for  each 
mission.  Nicastri’ s  program  determined  that  this  configuration  would  be  a  nightmare  for 
integration  and  configuration  control,  and  would  be  far  too  expensive.  Thus,  it  is  better  to 
start  with  the  maximum  capability  and  remove  fi’om  there  (Nicastri,  1996). 

The  approach  chosen  by  the  team  takes  ARPA’s  experience  into  consideration.  A 

modular  approach  wdll  be  used,  whereby  all  busses  are  manufactured  with  all  foreseeable 
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component  options  attached  via  removable  interfaces.  Of  course,  center  of  mass  and 
attitude  control  constraints  may  preclude  the  removal  of  some  excess  components, 
depending  on  the  characteristics  of  the  mission  module  in  question. 


15.1.6  Maximum  Capability 

The  Modsat  bus  must  accommodate  a  wide  variety  of  mission  modules,  and  must 
therefore  cater  to  the  most  demanding  customers.  This  implies  that  there  will  be  excess 
capability  on  many  missions.  Some  of  this  may  be  mitigated  by  the  modular  architecture 
discussed  above,  but  certainly  not  all  excess  capability  can  be  removed.  The  notion  of 
built-in  excess  that  will  accompany  the  mandated,  standardized  interface  is  a  feature  that 
may  encounter  resistance  from  industry.  According  to  Richard  Warner,  Chief  Technical 
Officer  of  AeroAstro  Corporation,  “satellite  designers  crave  efficiently  engineered, 
customized  packages”  (Warner,  1996).  However,  given  the  objectives  of  Modsat,  this 
cannot  be  avoided. 


15.1.7  On-Board  Propulsion 

As  mentioned  in  section  15.1.3,  the  team  decided  to  use  active  three-axis  control, 
with  propulsion  thrusters.  The  alternative  method  of  three-axis  control  is  passive  control, 
which  uses  gravity  gradient  techniques  or  magnetic  torquers  to  control  and  slew  the 
spacecraft.  According  to  Reeves,  “Passive  techniques  can  provide  coarse  control  to 
support  low-accuracy  pointing  requirements  and  simple  spacecraft”  (Reeves,  1992:304). 
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Magnetic  torquers  are  often  used  in  place  of  the  bulkier  propellant-thruster 
configurations  to  reduce  spacecraft  momentum.  However,  magnetic  torquers  cannot 
perform  AV  maneuvers  (Everett,  1996).  In  section  15.4,  it  will  be  shown  that  Modsat 
requires  AV  capability  to  maintain  its  altitude  at  LEO.  Moreover,  thrusters  are  required 
to  perform  tactical  repositioning  AV  maneuvers,  which  may  very  well  be  required  as  part 
of  Modsat’s  tactical  mission  profile  (see  Problem  Definition). 


15.1.8  Data  Processing 

Most  space  sensor  applications  require  some  degree  of  processing  of  the  mission 
data,  prior  to  its  transmission  to  the  ground.  In  any  given  custom-built  satellite,  it  is 
possible  for  such  data  to  be  handled  by  the  main  spacecraft  processor,  along  with  all  of  its 
other  processing  functions.  However,  each  mission  type  has  its  own  very  unique 
processing  requirements,  and  it  would  be  impossible  to  satisfy  all  with  one  processor.  In 
fact,  many  instruments  have  their  own  mini-computers.  Thus,  the  team  decided  that 
mission  data  processing  must  be  performed  by  the  mission  module.  However,  data 
storage  will  be  available  in  the  bus  processor,  as  stated  in  the  requirements. 


15.1.9  The  Bus-To-Mission  Module  Interface 

Another  key  part  of  this  study  is  the  specification  of  a  standardized  interface 
between  the  bus  and  all  mission  modules.  This  very  issue  has  been  addressed  by  the 
Aerospace  Corporation,  and  the  results  are  documented  in  “An  Approach  To  Rapid 
Payload  Integration:  The  Spacecraft-To-Payload  Interface  Guidehne  (SPIG),  Version  1” 
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(Aerospace  Corporation,  1996).  According  to  this  document,  “the  SPIG  is  intended  to 
serve  as  a  core  building  block  on  which  the  payload-to-spacecraft  interface  can  be 
designed.” 

In  the  production  of  the  SPIG,  much  systems  engineering  work  has  been 
accomplished  to  suggest  an  optimum  standardized  interface.  The  team  decided  to  use  the 
SPIG  interface  in  lieu  of  designing  their  own  interface. 


15.2  Reliability  Analysis 

15.2.1  Overview 

A  major  tradeoff  in  the  design  of  any  new  system  is  the  trade  between  the 
reliability  and  cost  of  a  system.  Due  to  the  generally  high  cost  of  past  and  present  space 
efforts,  this  takes  on  an  even  greater  level  of  importance.  In  addition,  the  current  emphasis 
on  finding  ways  to  do  the  space  mission  "better,  faster,  cheaper"  adds  further  importance 
to  this  trade.  Finding  the  optimum  level  of  reliability  to  meet  cost  and  performance  goals 
will  help  narrow  the  solution  space  of  the  system  design.  Thus,  as  part  of  the  overall 
system  design/analysis  process,  a  cost  vs.  reliability  trade  study  was  performed  to 
determine  the  starting  point  from  which  a  system-level  reliability  approach  should  proceed. 

The  formal  definition  of  "reliability"  adhered  to  in  this  design  project  is  "the 
probability  that  the  system  will  perform  its  intended  function  for  a  specified  interval  of 
time  under  stated  conditions"  (Ramakumar,  1993:3).  The  "stated  conditions"  assumed  in 
this  project  are  the  natural  (non-man-made)  hazards  common  to  the  low-Earth  orbit  space 
environment,  including  thermal,  vacuum,  and  radiation  hazards.  For  the  purposes  of  this 
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study,  it  is  assumed  that  the  spacecraft  has  survived  the  launch  and  has  been  successfully 
inserted  into  its  operational  orbit.  Thus,  mission  failures  attributed  to  the  launch  vehicle 
(including  the  kick  motor,  if  present)  were  not  considered.  This  does  not  mean  that 
failures  induced  by  launch  stresses  were  not  included.  Rather,  it  means  that  the  launch 
vehicle  successfully  placed  the  satellite  in  it’s  proper  orbit. 

As  part  of  the  cost  vs.  reliability  trade  study,  a  MATLAB  model  was  created  that 
allows  the  user  to  determine  the  overall  system  reliability  of  the  spacecraft  based  on  Mean 
Time  Between  Failures  (MTBF)  and  redundancy  levels  for  individual  subsystems.  The 
model  is  explained  in  detail  in  Volume  III  of  the  report. 

15.2.2  Reliability  Strategies 

As  previously  stated,  the  objective  of  the  cost  vs.  reliability  trade  study  was  to 
determine  the  optimum  starting  point  for  selecting  the  reliability  approach  to  be  used  in 
designing  the  spacecraft.  Two  approaches  were  studied;  fault  avoidance  and  fault 
tolerance.  "Fault  avoidance"  seeks  to  prevent  failure  by  tactics  such  as  providing  generous 
design  margins,  using  high-quality  parts,  and  thorough  inspection  and  testing  of  spacecraft 
components,  subsystems,  and  the  assembled  spacecraft  (Hecht,  1993:700).  In  contrast, 
"fault  tolerance"  seeks  not  to  fervently  avoid  failure,  but  to  allow  for  continued  spacecraft 
operation  despite  the  failure,  generally  through  either  equipment  redundancy  (i.e.  spares) 
or  functional  redundancy  (other  parts  of  the  spacecraft  not  optimized  for  a  particular 
function  assuming  the  duties  of  the  failed  equipment).  Equipment  and  functional 
redundancy  can  be  implemented  at  the  subsystem  level,  component  level,  or  within  a 
spacecraft  component  (e.g.  an  extra  gyroscope  within  an  inertial  measurement  unit) 


147 


(Hecht,  1992:701).  Within  the  context  of  this  study,  fault  avoidance  was  limited  to  using 
high-quality  parts,  and  fault  tolerance  was  limited  to  equipment  redundancy. 


15,2.3  Methodology 

In  considering  fault  avoidance  vs.  cost,  three  classes  of  components  were  studied: 
commercial-grade.  Class  B,  and  Class  S.  Commercial-grade  components  are  similar  to 
what  can  be  purchased  at  a  local  electronics  store  or  from  a  mail-order  catalog.  An 
example  would  be  purchasing  a  Pentium  processor  from  the  local  computer  store  and 
using  it  as  the  central  processing  unit  in  the  spacecraft's  Command  and  Data  Handling 
subsystem.  Such  hardware  is  generally  inexpensive  and  readily  available,  but  lack  the 
extensive  testing,  quality-control,  and  documentation  of  other  component  classes  (Hecht, 
1996:67,  76)  Class  B  components  can  be  thought  of  as  components  that  have  been  built 
and  tested  to  meet  general  military  specifications  and  standards  (MIL-SPEC/STD) 
(Muolo,  1993:3 15).  Because  of  the  often  rugged  environments  military  hardware  must 
operate  in,  they  tend  to  be  built  to  more  exacting  specifications,  such  as  government- 
approved  materials,  suppliers,  manufacturing  processes,  packaging,  and  transport  (Hecht, 
1996:67).  Class  B  component  must  endure  much  more  thorough  and  rigorous  testing  and 
must  often  be  accompanied  by  extensive  documentation  tracing  their  development  history, 
something  not  required  of  commercial-grade  components  (Hecht,  1992:700).  Class  S,  or 
"space-qualified"  components  are  considered  to  be  at  the  top  of  the  hierarchy  when  it 
comes  to  component  quality.  In  addition  to  the  requirements  imposed  on  Class  B 
components.  Class  S  components  are  subjected  to  additional,  space  environment-unique 

survivability  tests  and  are  always  accompanied  by  an  extensive  documentation  trail  tracing 
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their  history  (Hecht,  1996:68).  Accordingly,  the  costs  of  components  increase  as  one 
moves  up  the  quality  hierarchy. 

Fault  tolerance  vs.  cost  was  examined  by  comparing  spacecraft  cost  vs.  system 
redundancy  level.  Three  classes  of  redundancy  were  used:  single-string,  double-string,  and 
triple-string.  Single  string  means  that  only  the  subsystems  essential  to  an  operational 
spacecraft  are  included,  and  none  of  the  subsystems  are  duplicated.  Double  string  means 
that  all  essential  subsystems  have  one  primary  and  one  standby  that  can  be  brought  on-line 
by  activating  a  switch.  For  the  purposes  of  this  study,  the  switching  mechanism  is  assumed 
to  have  perfect  reliability.  In  reality,  this  is  not  the  case.  Despite  this,  as  long  as  this 
assumption  is  consistent  throughout  the  study,  it  should  have  no  effect  on  the  outcome, 
given  the  study's  comparative  nature.  The  concept  behind  triple  string  spacecraft  is 
identical  to  double  string,  except  each  primary  subsystem  has  two  standbys. 

A  third  approach  in  improving  spacecraft  reliability  was  not  included  in  the  study 
but  is  nonetheless  worthy  of  mention.  It  takes  a  holistic  approach  to  reliability 
optimization,  focusing  less  on  individual  components  and  subsystems  and  more  on  the 
"expected"  reliability  of  the  system  as  a  whole.  Enhancing  expected  reliability  differs 
(albeit  in  a  subtle  manner)  from  traditional  "predicted"  reliability  improvement  (the  goal  of 
fault  tolerance  and  fault  avoidance)  in  that  it  incorporates  measures  such  as  providing 
extra  protection  to  critical  components  from  the  space  environment,  operating 
components  and  subsystems  well  within  their  design  limits  (i.e.  de-rating  operational 
capability),  incorporating  generous  power  generation  capacity  to  allow  graceful 
degradation  on  orbit,  rigorous  system-level  testing,  and  other  system-level  measures. 
Expected  reliability  can  be  thought  of  as  an  "update"  to  the  original  predicted  reliability. 
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Nowadays,  designers  and  builders,  particularly  of  small,  short-mission  satellites,  are 


finding  techniques  that  focus  on  the  overall  system-level  as  a  more  accurate  and  cost- 
effective  means  of  predicting  and  improving  reliability  (Everett,  1996;  Nicastri,  1996; 
Jackson,  1996;  Warner,  1996).  The  following  concept  map  illustrates  the  complexities  of 
the  cost-reliability  relationship. 


Figure  15-1;  Cost-Reliability  Concept  Map 

The  data  used  in  this  study  comes  primarily  fi-om  a  study  of  on-orbit  spacecraft 

failures  from  the  early  1960s  to  1984,  published  by  Rome  Air  Development  Center,  Air 
Force  Systems  Command.  The  study  examined  failures  in  over  300  satellites  from  96 
programs  (Hecht,  1985;  1).  Failures  are  broken  out  by  cause,  severity,  affected  subsystem, 
failure  date/time,  and  other  parameters  (Hecht,  1985:7).  Throughout  the  study,  various 
combinations  of  failures  are  examined  and  patterns  are  noted  where  evident. 
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15.2.4  Assumptions 


Data  was  extracted  from  the  report  using  the  following  assumptions  (Hecht, 
1985:62-109): 

1.  Only  consider  post- 1977  failure  data  (allows  for  technology  differences  pre- 
and  post- 1977) 

2.  Mission  length  before  failure  does  not  exceed  one  year 

3.  Only  the  following  classes  of  failures  were  considered  relevant: 

Class  1  (Critical  Failure  —  Entire  satellite  or  a  major  mission  function  fails) 
Class  2  (Single  Point  Failure  —  Major  assembly  or  component  failure) 

Class  5  (Degraded  Performance  --  Degraded  performance  of  a  mission 

function) 

In  addition,  the  following  assumptions  were  also  applied: 

4.  Components  and  subsystems  in  the  RADC  report  are  assumed  to  be  Class  B 
(This  seems  logical  for  two  reasons:  a)  Class  S  parts  were  not  available  until  after  the  early 
1980s  (Hecht,  1996:295);  b)  the  idea  of  using  ordinary  commercial  grade,  non- 
MILSPEC/STD  or  Class  S  components  for  space  applications  is  a  relatively  new 
phenomenon). 

5.  The  failure  rates  of  Class  S  components  are  approximately  25%  of  Class  B 
components  and  10%  of  high-grade  commercial  components  (Hecht,  1992:700). 

6.  The  cost  of  Class  S  components  is  roughly  four  times  the  cost  of  Class  B 
components,  and  roughly  ten  times  the  cost  of  commercial-grade  components  (this 
assumption  was  examined  in  the  sensitivity  analysis). 
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7.  The  recurring  (i.e.  production)  cost  of  the  spacecraft  is  approximately  $30M 
(derived  from  the  Cost  Modeling  section  in  Vol.  Ill  of  the  thesis). 

15.2.5  Analysis 

Given  these  assumptions,  the  overall  satellite  failure  rate  under  the  stated 
assumptions  was  determined  by  the  following  procedure: 

Total  #  of  failures  (pre-  and  post-1977)  =  2346  (Hecht,  1985:96-97) 

Total  #  of  flights  (pre-  and  post-1977)  =  321  (Hecht,  1985:96-97) 

Overall  failure  rate  =  2346/321  =  7.308  failures/spacecraft-year 
Since  the  post-1977  overall  failure  rate  is  roughly  twice  the  pre-1977  overall  failure  rate 
(Hecht,  1985:49),  pre-1977  failures  should  account  for  one-third  of  the  total  overall 
failure  rate,  and  post-1977  failures  should  account  for  the  remaining  two-thirds.  Hence, 
Pre-1977  failure  rate  =  1/3  x  7.308  =  2.436  failures/spacecraft-year 
Post- 1977  failure  rate  =  2/3  x  7.308  =  4.872  failures/spacecraft-year 
#  of  failure  due  to  bus  (pre-  and  post-1977)  =  1832  (Hecht,  1985:73) 

Total  #  of  failures  =  2469  (considered  valid  despite  slight  (~5%)  discrepancy  with 
above  number)  (Hecht,  1985:73) 

The  percentage  of  failures  attributable  to  the  bus  was  74.2%.  (Hecht,  1985:73)  Hence, 
Computed  failure  rate  for  bus,  post-1977  =  4.872  (0.742)  =  3.615 
failures/spacecraft-year 

The  fraction  of  Class  1,2,  and  5  failures  were  given  as  follows:  (Hecht,  1985:52) 

%  of  failures  that  were  Class  1  =  3% 

%  of  failures  that  were  Class  2  =  5% 
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%  of  failures  that  were  Class  5  =  20% 

Therefore, 

Failure  rate  (bus,  post-1977,  Class  1,2,  and  5  failures)  =  (0.03+0.05+0.20)  x  3.615 
=  1.0122  failures  per  spacecraft-year 

The  fraction  of  failures  during  the  first  year  of  on-orbit  operations  as  broken  out  according 
to  subsystem  is  as  follows:  (Hecht,  1985:75) 

Telemetry,  Tracking,  and  Commanding  (TTC)  =  0.400 

Guidance  and  Control  (ADCS)  =  0.133 

Power  (EPDS)  =  0.150 

Data  Handling  (CDH)  =  0.200 

Thermal  =  0.067 

Propulsion  =  0.050 

Structure  =  0 

Thus,  for  a  one-year  mission  under  the  previously  stated  assumptions,  the  failure  rates  are 
as  follows  (let  X  represent  failure  rate): 

X.rrc  =  0.400  (1.0122)  =  0.40488  failures/spacecraft-year 
^Abcs  =  0.133  (1.0122)  =  0.13462  failures/spacecrafl-year 
?^<EPDs  -  0.150  (1.0122)  =  0.15183  failures/spacecraft-year 
Xcdh  =  0.200  (1.0122)  =  0.20244  failures/spacecrafl-year 
/^Thennai  =  0.067  (1.0122)  =  0.06782  failures/spacecrafl-year 
^Propulsion  =  0.050  (1.0122)  =  0.05061  failures/spacecrafl-year 
^stnicture  =  0  (1.0122)  =  0  failures/spacecraft-year 
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In  order  to  account  for  the  advancement  of  technology  since  1984  (and  a  corresponding 
increase  in  component  reliability),  the  above  failure  rates  were  divided  by  an 
"improvement  factor".  The  improvement  factor  was  calculated  by  taking  Xcdh  and  dividing 
it  by  the  failure  rate  of  a  modem  Class  B  CDH  subsystem  (Berget  and  Turner,  1992:389) : 
Improvement  factor  =  Xcdh  /  modem  CDH  failure  rate 
=  0.20244/0.05462  3.7 

An  assumption  implicit  in  the  use  of  this  factor  is  that  all  subsystems  have  improved  by  a 
factor  of  3.7  since  1984.  Dividing  the  failure  rates  of  all  of  the  subsystems  by  3.7, 

X,TTc  =  0.109427  failures/spacecraft  Xxhennai  =  0.01833  failures/spacecraft 
^ADcs  =  0.036384  failures/spacecraft  Xpropuision  =  0.013678  failures/spacecraft 
^EPDs  =  0 . 04 1 03  5  failures/ spacecraft  Xstmcture  =  0  failures/ spacecraft 
^CDH  =  0.054714  failures/spacecraft 

In  order  to  compute  subsystem  reliability  and  determine  the  effects  of  standby  redundancy, 
the  following  formulas  were  used  (Ramakumar,  1993:196)  : 

R(t)  =  e‘^*  No  redundancy  (i.e.  single-string) 

R(t)  =  e'^‘  [  1+X,t  ]  Single  redundant  unit  (i.e.  double-string) 

R(t)  =  e‘^‘  [  1+  >.t  +  (Xt)^/2!  ]  Two  redundant  units  (i.e.  triple-string) 
where  R(t)  =  reliability 

t  =  time  (t  =  1,  one  year) 

X  =  failure  rate  (failures  per  spacecraft  over  the  1-  year  time  period) 

The  results  are  listed  in  Table  15-2,  Table  15-3,  and  Table  15-4. 
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Table  15-2:  Reliability  and  Failure  Probability  for  a  1-year  Mission; 


Single-string  Spacecraft 


Reliability 

Failure  Probability 

Subsystem 

Class  B 

Class  S 

Commercial 

Class  B 

Class  S 

Commercial 

TT&C 

0,8963476 

0.9730141 

0.760661 

0.103652 

0.026986 

0.2393391 

ADCS 

0.9642702 

0.9909453 

0.913055 

0.03573 

0.009055 

0.0869453 

EPDS 

0.9597954 

0.9897937 

0.902499 

0.040205 

0.010206 

0.0975011 

CDH 

0.9467563 

0.9864147 

0.872159 

0.053244 

0.013585 

0.1278412 

Thermal 

0.9818372 

0.9954281 

0.95521 

0.018163 

0.004572 

0.0447902 

Propulsion 

0.9864147 

0.9965862 

0.966382 

0.013585 

0.003414 

0.0336179 

Structure 

1 

1 

1 

0 

0 

0 

SYSTEM 

0.7606609 

0.9338944 

0.504635 

0.239339 

0.066106 

0.4953645 

Table  15-3:  Reliability  and  Failure  Probability  for  a  1-year  Mission; 


Double-string  Spacecraft 


Reliability 

Failure  Probability 

Subsystem 

Class  B 

Class  S 

Commercial 

Class  B 

Class  S 

Commercial 

TT&C 

0.9944322 

0.9996326 

0.968753 

0.005568 

0.000367 

0.0312469 

ADCS 

0.9993539 

0.9999589 

0.996106 

0.000646 

4.11E-05 

0.0038943 

EPDS 

0.9991807 

0.9999477 

0.995084 

0.000819 

5.23E-05 

0.0049157 

CDH 

0.9985567 

0.9999073 

0.991456 

0.001443 

9.27E-05 

0.008544 

Thermal 

0.999834 

0.9999895 

0.998982 

0.000166 

1.05E-05 

0.0010184 

Propulsion 

0.9999073 

0.9999942 

0.999428 

9.27E-05 

5.83E-06 

0.0005715 

Structure 

1 

1 

1 

0 

0 

0 

SYSTEM 

0.991286 

0.9994303 

0.950519 

0.008714 

0.00057 

0.0494805 
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Table  15-4:  Reliability  and  Failure  Probability  for  a  1-year  Mission; 


Triple-string  Spacecraft 


Reliability 

Failure  Probability 

Subsystem 

Class  B 

Class  S 

Commercial 

Class  B 

Class  S 

Commercial 

TT&C 

0.9997988 

0.9999967 

0.997217 

0.000201 

3.34E-06 

0.0027833 

ADCS 

0.9999922 

0.9999999 

0.999883 

7.81E-06 

1.25E-07 

0.0001172 

EPDS 

0.9999888 

0.9999998 

0.999833 

1.12E-05 

1.79E-07 

0.0001667 

CDH 

0.9999738 

0.9999996 

0.999615 

2.62E-05 

4.22E-07 

0.0003851 

Thermal 

0.999999 

1 

0.999985 

l.OlE-06 

1.6E-08 

1.55E-05 

Propulsion 

0.9999996 

1 

0.999994 

4.22E-07 

6.65E-09 

6.496E-06 

Structure 

1 

1 

1 

0 

0 

0 

SYSTEM 

0.9997522 

0.9999959 

0.996528 

0.000248 

4.09E-06 

0.0034721 

Table  15-5  combines  the  system  reliability  data  in  the  tables  above  with  the  appropriate 
cost  figures,  using  a  $30M  class  S  spacecraft  as  the  baseline: 

Table  15-5:  Spacecraft  Cost  vs.  Reliability  (1st  Cost  Assumption) 


Class 

R(t=lyr) 

Cost  ($M) 

Commercial,  IX 

0.504635 

3 

Commercial,  2X 

0.950519 

6 

B,  IX 

0.760661 

7.5 

Commercial,  3X 

0.996528 

9 

B,2X 

0.991286 

15 

B,  3X 

0.999752 

22.5 

S,  IX 

0.933894 

30 

S,  2X 

0.99943 

60 

S,  3X 

0.999996 

90 

Table  15-6  shows  the  results  of  changing  the  cost  assumption  (Assumption  #  6)  so 
that  the  cost  ratio  from  commercial  class  to  Class  B  (5;  1)  is  the  same  as  going  from  Class 
B  to  Class  S.  A  $30M  Class  S  spacecraft  is  still  the  baseline. 
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Table  15-6:  Spacecraft  Cost  vs.  Reliability  (2nd  Cost  Assumption) 


Class 

R(t=lyr) 

Cost  ($M) 

Commercial,  IX 

0.504638 

1.2 

Commercial,  2X 

0.950519 

2.4 

Commercial,  3X 

0.996528 

3.6 

B,  IX 

0.760661 

6 

B,  2X 

0.991286 

12 

B,  3X 

0.999752 

18 

S,  IX 

0.933894 

30 

S,  2X 

0.99943 

60 

S,  3X 

0.999996 

90 

Table  15-7  shows  the  results  of  changing  the  cost  assumption  again  so  that  the  cost  of 
Class  S  is  300%  of  commercial  and  Class  B  is  200%  of  commercial,  with  a  $30M  Class  S 
spacecraft  as  a  baseline. 

Table  15-7:  Spacecraft  Cost  vs.  Reliability  (3rd  Cost  Assumption) 


Class 

R(t=lyr) 

Cost  ($M) 

Commercial,  IX 

0.50464 

10 

Class  B,  IX 

0.76066 

20 

Commercial,  2X 

0.95052 

20 

Class  S,  IX 

0.93389 

30 

Commercial,  3X 

0.99653 

30 

Class  B,  2X 

0.99129 

40 

Class  S,  2X 

0.99943 

60 

Class  B,  3X 

0.99975 

60 

Class  S,  3X 

1 

90 

Graphical  depictions  of  the  data  are  in  Figure  15-2,  Figure  15-3,  and  Figure  15-4: 
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Figure  15-2:  Cost  vs.  Spacecraft  Reliability  Improvement  Under  1st  Cost 

Assumption 


Figure  15-3:  Cost  vs.  Spacecraft  Reliability  Improvement  Under  2nd  Cost 

Assumption 


158 


Figure  15-4:  Cost  vs.  Spacecraft  Reliability  Under  3rd  Cost  Assumption 

An  exponential  curve  has  been  fitted  to  the  data  in  all  three  cases,  superimposed 

over  the  original  data.  It  can  be  seen  that  the  optimum  choices  between  cost  and  reliability 
(i.e.  the  "knee"  of  the  fitted  curve)  seems  to  be  a  single-string.  Class  B  spacecraft,  or  a 
double  or  triple-string  spacecraft  with  commercial  components. 


Table  15-8:  Cost  and  Reliability  for  Spacecraft  with  Various  Class/Redundancy 

Levels 


Cost  Assun^ttion  #1 

Class 

R(t=lvr) 

Class 

Rft=lvrl 

Class 

3 

0.50464 

comm,  IX 

7.5 

0.76066 

Class  B,  IX 

30 

0.933894 

Class  S,  IX 

6 

0.95052 

comm,  2X 

15 

0.99129 

Class  B,  2X 

60 

0.99943 

Class  S,  2X 

9 

0.99653 

comm,  3X 

22.5 

0.99975 

Class  B,  3X 

90 

0.999996 

Class  S,  3X 

Cost  Assumption  #2 

■asm 

Class 

mSSfImm 

Class 

Rft=lvrl 

Class 

1.2 

0.50464 

comm,  IX 

6 

0.76066 

Class  B,  IX 

30 

0.933894 

Class  S,  IX 

2.4 

0.95052 

comm,  2X 

12 

0.99129 

Class  B,  2X 

60 

0.99943 

Class  S,  2X 

3.6 

0.99653 

comm,  3X 

18 

0.99975 

Class  B,3X 

90 

0.999996 

Class  S,  3X 

Cost  Assumption  #3 

■3BRH 

Class 

■3SRH 

Class 

Rft=lvr) 

Class 

10 

0.50464 

comm,  IX 

20 

0.76066 

Class  B,  IX 

30 

0.933894 

Class  S,  IX 

20 

0.95052 

comm,  2X 

40 

0.99129 

Class  B,  2X 

60 

0.99943 

Class  S,  2X 

30 

0.99653 

comm,  3X 

60 

0.99975 

Class  B,  3X 

90 

0.999996 

Class  S,  3X 
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R(t*1  yr) 


Figure  15-5:  Cost  vs.  Reliability  for  Different  Component  Classes  (1st  Cost 

Assumption) 


Figure  15-6:  Cost  vs.  Reliability  for  Different  Component  Classes  (2nd  Cost 

Assumption) 
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Figure  15-7;  Cost  vs.  Reliability  for  Different  Component  Classes  (3rd  Cost 

Assumption) 


Figure  15-5,  Figure  15-6,  and  Figure  15-7  show  a  marked  increase  in  reliability  in  going 
from  single-string  Class  B  to  redundant  commercial-grade  components  for  about  the  same 
cost.  However,  it  is  vital  to  note  that  the  assumption  about  the  increase  in  costs  between 
redundancy  levels  do  not  take  into  account  the  additional  costs  associated  with  redundant 
systems  such  as  added  launch  costs  (due  to  extra  weight),  the  costs  of  testing  and 
integrating  redundant  components,  and  other  "hidden"  costs.  If  these  costs  were  to  be 
added,  the  cost-reliability  advantage  of  commercial-class  with  redundancy  would  be 
reduced. 

15.2.6  Conclusion 

Given  today's  push  towards  small,  inexpensive  spacecraft,  the  spacecraft  designer 
can  no  longer  afford  to  maximize  reliability  without  regard  to  cost.  The  sky  is  no  longer 
the  limit  insofar  as  performance  requirements  are  concerned,  and  in  the  context  of 
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reliability,  desired  reliability  must  be  balanced  with  costs.  A  detailed  study  of  past 
spacecraft  failures  combined  with  some  simple  assumptions  on  cost  showed  that  a 
commercial-class  with  redundancy  would  be  a  good  starting  point  in  optimizing  reliability 
and  cost.  Of  course,  depending  on  program  cost  and  performance  goals  and  the 
availability  of  Class  B  and  Class  S  components,  the  designer  should  tailor  the  cost- 
reliability  balance  to  mission  needs.  Finally,  it  is  likely  that  an  even  better  balance  can  be 
achieved  by  designing  the  spacecraft  using  high-reliability  components  and  multiple- string 
schemes  into  those  subsystems  that  would  benefit  the  most  (TT&C,  CDH),  instead  of  an 
all-or-nothing  approach. 

15.3  Launch  Vehicle  Considerations 

Although  launch  vehicle  (LV)  considerations  are  in  the  external  environment  of  the 
engineering  of  the  spacecraft  bus,  the  LV  payload  constraints  have  a  great  influence  on  the 
design  of  the  bus.  Thus,  even  though  the  design  and  configuration  of  a  launch  vehicle 
was  not  a  goal  of  the  design  team,  it  was  necessary  to  choose  a  launch  vehicle 
configuration  .  This  choice  placed  constraints  on  the  design  of  the  alternatives.  The 
sponsor’s  guidance  required  the  satellite  bus  to  be  within  the  Pegasus  and  Lockheed 
Martin  Launch  Vehicle  (LMLV)  weight  class  (Rooney,  1996).  Therefore,  the  team 
decided  to  choose  one  of  these  launch  vehicles. 

The  selection  of  a  launch  vehicle  for  this  project  could  have  become  a  complex  and 
intricate  study  within  itself  Given  the  limited  time  and  resources  of  this  study,  the  team 
decided  to  select  a  LV  that  met  the  tactical  needs  of  the  sponsor  and  provided  enough 
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energy  to  put  the  desired  spacecraft  weight  class  into  orbit.  The  Pegasus  XL  was  chosen 
as  the  baseline  LV.  This  decision  was  based  on  the  success  and  experience  of  Orbital 
Science  Corporation’s  Pegasus  LVs.  The  air-launched  nature  of  the  Pegasus  vehicles 
offers  a  tactical  advantage  over  other  conventional  ground-based  LVs.  The  capability  of 
being  rapidly  deployed  and  launched  into  any  inclined  Low  Earth  Orbits  (LEO)  from  any 
latitude  and  longitude  is  another  distinct  advantage  of  the  Pegasus.  More  specifically,  the 
Pegasus  XL  was  chosen  over  the  standard  Pegasus  vehicle  because  the  XL  version  offers 
more  mass-to-orbit  performance.  Other  small  satellite  programs  have  also  selected  the 
Pegasus  XL  as  the  LV  of  choice  (Wertz,  1996:350).  One  such  program  is  NASA’s  Small 
Explorer  (SMEX)  program,  which  provides  standardized  buses  for  observation  missions 
(Small  Explorer,  1996:WWWeb). 

It  should  be  noted  that  the  launch  vehicle  of  choice  can  be  changed  in  future 
studies.  However,  the  choice  of  LV  strongly  influences  the  design  of  the  bus.  Thus,  if  the 
LV  is  changed  to  a  booster  other  than  the  Pegasus  XL,  spacecraft  bus  designs  may  differ 
from  those  produced  in  this  study. 

15.3.1  Pegasus  XL 

The  Pegasus  XL  is  a  winged,  three-stage,  solid  rocket  booster  that  weighs 
approximately  22,680  kg  (50,000  Ibm)  and  measures  16.9  m  (55.4  ft)  in  length  and  1.27 
m  (50  in)  in  diameter.  An  expanded  view  of  the  vehicle  is  shown  in  Figure  15-8.  The 
rocket  is  lifted  by  a  carrier  aircraft,  usually  a  Lockheed  L- 101 1,  to  a  level  flight  condition 
about  1 1,580  m  (38.000  ft)  and  Mach  0.79  before  it  is  released  for  launch  (Orbital  Science 
Corporation,  1993:2-1). 
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Source;  OSC,  1993:2-2 

Figure  15-8:  Pegasus  XL  Expanded  View 
There  are  two  major  Pegasus  XL  features  that  impose  restrictions  on  potential 

satellite  bus  designs.  One  is  the  Pegasus  XL  mass-to-orbit  performance  capability;  the 

other  is  the  booster’s  payload  fairing  dimensions. 


15.3.2  Mass-to-Orbit  Performance 

An  important  characteristic  of  any  launch  vehicle  is  the  amount  of  mass  it  can 
place  into  orbit.  The  mass  that  the  Pegasus  XL  can  deliver  depends  on  the  altitude  and 
inclination  of  the  desired  orbit,  and  whether  the  booster  uses  an  optional  Hydrazine 
Auxiliary  Propulsion  System  (HAPS). 

The  purpose  of  the  HAPS  is  twofold.  It  improves  orbital  injection  accuracy  and 
increases  mass-to-orbit  capability  for  satellites  placed  into  altitudes  greater  than 
approximately  600  kilometers.  The  HAPS  contains  a  centrally  mounted  tank  loaded  with 
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72  kilograms  of  hydrazine,  a  highly  pressurized  regulated  gas  source,  and  three  fixed, 
axially  directed  thrusters  (OSC,  1993:2-6).  The  mass-to-orbit  performance  capability  for 
the  Pegasus  XL  is  provided  in  Figure  15-9. 


■  n^laai  ftiMWiFfciLWilgtl* 
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Source;  OSC,  1993:3-3 

Figure  15-9:  Pegasus  XL  Performance  Capability 


15.3.3  Payload  Fairing 

The  fairing  of  the  launch  vehicle  places  size  and  shape  constraints  on  the  potential 
satellite  design.  Therefore,  it  is  important  to  a  satellite  designer  to  understand  these 

constraints.  Pegasus  XL  offers  two  payload  interfaces:  a  38  inch  diameter  interface  plate 
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and  a  23  inch  diameter  interface  plate.  Both  of  these  interface  plates  can  be  used  with  or 
without  HAPS.  Figure  15-10  shows  the  payload  fairing  with  the  38  inch  interface.  If  this 
configuration  is  used  with  the  optional  HAPS,  the  spacecraft  design  will  lose  14.65  inches 
from  the  available  84.22  inch  height.  Figure  15-11  depicts  the  23  inch  configuration 
without  HAPS.  When  the  HAPS  is  used  with  the  23  inch  interface,  4.2  inches  are 
deducted  from  the  70.57  inch  height. 


Source:  OSC,  1993:5-3 


Figure  15-10:  Payload  Fairing  with  38  inch  Interface 


166 


Source:  OSC,  1993:5-4 

Figure  15-11:  Payload  Fairing  with  23  inch  Interface 


15.3.4  Hydrazine  Auxiliary  Propulsion  System 

The  team  questioned  whether  or  not  a  HAPS  should  be  included  as  part  of  the 
launch  vehicle.  The  inclusion  of  a  HAPS  mandates  additional  restrictions  on  the  height, 
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mass  and  volume  of  the  spacecraft,  in  a  trade  for  added  accuracy  and/or  higher  orbit 
insertion.  It  was  decided  that  the  vast  majority,  if  not  all,  of  the  Modsat  missions  would 
not  require  orbital  altitudes  above  600  kilometers.  Additionally,  orbital  insertion  accuracy 
is  mission  specific  and  depends  on  mass,  targeted  orbit,  and  the  particular  guidance 
strategy  adopted  for  the  mission  (OSC,  1993:3-5).  Thus,  the  team  decided  to  exclude  the 
HAPS  configuration  from  consideration.  This  decision  allowed  greater  flexibility  in 
generating  alternative  designs  for  the  satellite  bus. 

15.3.5  Other  Considerations 

Many  other  characteristics  of  the  Pegasus  XL  influenced  and  constrained  the 
design  effort.  These  characteristics  are  listed  in  the  Commercial  Pegasus  User’s  Guide. 
One  of  the  constraints  pertains  to  the  spacecraft  center  of  mass,  which  must  be  within  1.5 
inches  of  the  launch  vehicle’s  center  of  mass  in  both  the  Y  and  Z  axes.  (Jim,  we  need  a 
picture  of  the  coordinate  frame  of  reference  here,  if  possible).  The  X-axis  position  of  the 
spacecraft  center  of  mass  can  not  exceed  30  inches  above  the  LV-to-spacecraft  interface 
plate  without  severe  restrictions  being  placed  on  the  total  mass  of  the  spacecraft.  (OSC, 
1993:5-13) 

Another  factor  to  consider  is  that  the  spacecraft’s  stiffness  in  the  Z-axis  must  be 
greater  than  20  Hertz  to  avoid  dynamic  coupling  with  the  launch  vehicle  (OSC,  1993:5- 
15).  The  maximum  spacecraft  mass  is  also  limited  due  to  critical  shear  stresses 
experienced  at  the  interface  plate.  The  maximum  mass  that  can  be  integrated  with  the  38 
inch  interface  plate  is  454.6  kilograms  (1000  Ibm),  while  the  maximum  mass  for  the  23 
inch  interface  plate  is  318.2  kilograms  (700  Ibm)  (OSC,  1993:5-9).  Additional 

considerations  are  the  axial  and  lateral  loads  experienced  during  the  captive  carry,  drop, 
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and  launch  environments.  According  to  the  Pegasus  User’s  Guide,  maximum  axial 
accelerations  can  range  from  -4.2  to  13  times  the  force  of  gravity  (-4.2  to  13G’s).  The 
maximum  acceleration  due  to  horizontal  lateral  loading  is  between  +/-  l.SG’s.  The 
maximum  vertical  acceleration  is  between  +/-  4.0G’s. 

To  ensure  that  the  design  alternatives  do  not  violate  the  Pegasus  XL  constraints, 
launch  vehicle  compatibility  testing  was  incorporated  into  the  Modsat  model  through  3-D 
surface  rendering  visualization  (see  Volume  III). 


15.4  Baseline  Orbit  and  Allowable  Launch  Mass 
15.4.1  Baseline  Orbit-Type 

Section  15.3  demonstrated  that  sun-synchronous  orbits  are  the  most  weight 
restrictive  orbits  for  a  launch  vehicle,  and  many  mission  applications  may  require  a  sun- 
synchronous  orbit.  Therefore,  the  bus  should  be  light  enough  to  allow  for  such  missions. 
But  in  order  to  establish  a  baseline  launch  mass,  a  baseline  orbital  altitude  must  be 
determined.  This  altitude  will  not  be  dictated  to  mission  planners;  in  reality,  they  have  the 
latitude  to  select  an  appropriate  orbit,  provided  their  spacecraft  meet  the  launch  mass 
constraint. 

Nevertheless,  the  team  needed  a  maximum  mass  limit  for  design  purposes.  Recall 
from  the  Value  System  Design  section  that  one  of  the  measures  of  effectiveness  for  this 
study  is  allowable  mission  module  mass.  For  the  baseline  orbital  altitude,  this  mass  is  the 
allowable  launch  mass  less  the  mass  of  the  bus.  The  challenge  was  to  find  the  optimum 
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sun-synchronous  orbit  for  design,  and  therefore,  the  spacecraft  mass  limit.  The  optimum 
orbit  is  defined  as  that  which  maximizes  the  allowable  launch  mass. 

15.4.2  Mass  to  Altitude  Tradeoff 

This  section  details  the  analysis  that  was  performed  in  order  to  determine  the 
optimum  sun-synchronous  orbital  altitude  for  design  purposes.  It  is  essentially  a  study  of 
the  tradeoff  between  the  mass  carriage  capacity  of  the  launch  vehicle  for  a  given  altitude 
and  the  amount  of  propellant  to  required  to  maintain  that  altitude  for  one  year. 

The  mass-to-orbit  performance  of  a  launch  vehicle  decreases  as  the  orbital  altitude 
increases.  Thus,  lower  altitudes  are  desirable  for  large  payloads.  The  performance 
capability  of  the  Pegasus  LV  for  sun-synchronous  orbits  is  shown  in  Figure  15-12. 


Altitude  (Km) 

Source:  OSC,  1993:3-3 

Figure  15-12:  Launchable  Mass  Capacity  for  Sun-synchronous  Orbits 


However,  as  the  orbital  altitude  decreases,  the  requirement  for  AV  performance  to 
maintain  altitude  increases.  The  reason  for  this  is  simple.  At  the  lower  altitudes. 
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atmospheric  drag  on  the  spacecraft  is  significant.  The  spacecraft  must  provide  thrust  (AV) 
to  counter  this  drag  and  maintain  altitude.  The  AV  vs.  altitude  curve  is  shown  in  Figure 
15-13. 


Figure  15-13;  The  AV  to  Maintain  Altitude  per  Year 

Since  A  V  is  provided  through  the  use  of  propellant,  the  amount  of  propellant  on¬ 
board  the  spacecraft  is  proportional  the  AV  required  to  maintain  altitude.  This  statement 
assumes  that  the  amount  of  propellant  reserved  for  other  uses  (see  section  15.5.2.1)  does 
not  depend  on  the  altitude.  In  fact,  for  this  study,  it  is  assumed  that  the  mass  of  the  bus 
(constructed),  with  the  exception  of  the  propellant,  is  independent  of  orbital  altitude. 
Thus,  this  analysis  seeks  to  maximize  the  available  launch  mass,  defined  as  the  allowable 


*  AV  to  maintain  altitude  assuming  a  ballistic  coefficient  of  Bo^m/CdA=100  kg/m^. 
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launch  mass  for  a  sun-synchronous  orbit,  less  the  mass  of  the  propellant  reserved  for 
altitude  maintenance: 

Available  Mass  =  Launchable  Mass  -  Propellant  Mass 
where  the  launchable  mass  for  a  given  altitude  is  determined  from  Figure  15-12. 

For  the  a  given  amount  of  AV,  the  corresponding  propellant  mass  is  given  by  (Sackheim 
and  others,  1995:641); 


-1 


=  m\\ 


(Eqn  15-1) 


where  mf=  nio  -  mp :  the  final  vehicle  mass 

m<, :  initial  vehicle  mass  (launchable  mass,  found  from  Figure  15-12) 
mp :  mass  of  propellant  consumed 
Isp  ;  specific  impulse 

g  :  gravitational  constant  which  is  9.802  m/s^ 


For  this  analysis,  the  chosen  propellant  is  the  hydrazine  blend  with  the  highest  specific 
impulse  (24%  HN,  76%  N2H4;  Isp=263  m/s)  from  among  the  mono-propellant  database 
used  in  this  study  (see  section  15.5.2.3.1). 

By  substituting  this  expression  for  propellant  mass  into  the  previous  equation,  the 
available  launch  mass  becomes  a  function  of  allowable  launch  mass  and  AV,  both  of  which 
are  functions  of  orbital  altitude.  Thus,  available  launch  mass  is  essentially  a  function  of 
one  variable,  orbital  altitude.  It  is  desirable  to  find  the  altitude  that  maximizes  this 
fimction.  Figure  15-14  shows  the  function  of  available  launch  mass  vs.  orbital  altitude.  It 
is  clear  that  this  function  is  maximized  at  350  km  altitude,  since  the  available  mass 
increases  with  altitude  until  350  km.  Beyond  this,  the  AV  requirement  decreases  but  the 
allowable  launch  mass  decreases  dramatically. 
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Thus,  the  baseline  design  altitude  was  chosen  to  be  350  km.  Referring  again  to 
Figure  15-12,  it  can  be  seen  that  at  this  altitude  the  Pegasus  can  launch  approximately  308 
kg  into  sun-synchronous  orbit.  In  satisfaction  of  the  objective,  “Maximize  allowable 
mission  module  weight,”  this  allowable  mass  is  308  kg  less  the  mass  of  the  bus. 


173 


Altitude  (Km) 


Figure  15-14:  Available  Mass  for  the  Spacecraft 
(Not  Including  Propulsion  Subsystem) 


174 


15.5  Subsystem  Level 

Tradeoff  analyses  were  performed  at  the  subsystem  level,  in  order  to  further 
narrow  the  solution  space.  The  subsystems  of  Modsat  are  described  below: 


Table  15-9:  Spacecraft  Subsystems 


Subsystem 

Principal  Functions 

Other  Names 

Attitude  Determination  and 

Provides  determination  and 

Attitude  Control  System 

Control  System  (ADCS) 

control  of  attitude  and  orbit 
position,  plus  pointing  of 
spacecraft  and  appendages 

(ACS),  Guidance, 

Navigation  and  Control 
(GN&C)  System,  Control 
System 

Propulsion 

Provides  thrust  to  adjust 
orbit  and  attitude,  and  to 
manage  angular  momentum 

Reaction  Control  System 
(RCS) 

Structures  and  Mechanisms 

Provides  support  structure, 
booster  adapter,  and  moving 
parts 

Structure  Subsystem 

Thermal  Control 

Maintains  equipment  within 
allowed  temperature  ranges 

Environmental  Control 

System 

Telemetry,  Tracking  and 

Communicates  with  ground 

Communication  (Comm) 

Command  (TT&C) 

and  other  spacecraft; 
spacecraft  tracking 

Electrical  Power  System 
(EPS) 

Generates,  stores,  regulates, 
and  distributes  electric 
power 

Power 

Source:  Reeves,  1992:287 


15.5.1  Attitude  Determination  and  Control 

15.5.1.1  Introduction 

The  purpose  of  the  Attitude  Determination  and  Control  Subsystem  (ADCS)  is  to 
(1)  stabilize  the  spacecraft  against  disturbing  torques  imposed  by  both  the  natural  space 
environment  and  the  spacecraft's  own  internal  mechanisms,  and  (2)  maneuver  and  orient 
the  spacecraft  in  response  to  commands  issued  from  the  control  station.  Stabilization  and 
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control  can  be  accomplished  via  multiple  techniques.  These  include  gravity-gradient, 
magnetic,  pure-spin,  dual-spin,  one-axis  bias  momentum,  and  three-axis  stabilization 
(Etemo,  1992:346).  The  ADCS  itself  can  be  grouped  into  three  distinct  sections:  (a) 
attitude  sensors,  (b)  actuators,  and  (c)  control  logic/control  computers.  Attitude  sensors 
come  in  several  varieties,  including  Sun  sensors.  Earth-horizon  sensors,  star  sensors, 
magnetometers,  and  inertial  measurement  units  (IMUs)  (Etemo,  1992:360).  There  are  also 
several  types  of  actuators,  including  reaction  wheels,  momentum  wheels,  control-moment 
gyros  (CMGs),  electromagnetic  torquers,  and  thmsters  (Etemo,  1992:355).  Each 
stabilization,  sensing,  and  control  technique  has  it's  own  advantages  and  disadvantages. 
The  optimum  combination  of  stabilization  and  control  technique  and  ADCS  depends 
largely  on  the  spacecraft  system  performance  requirements  imposed  on  the  ADCS,  and  to 
a  lesser  extent,  constraints  imposed  by  other  satellite  subsystems  (including  the  payload). 
The  sensors,  control  logic,  and  actuators  are  tied  together  with  the  satellite's  dynamics  and 
disturbance  torques  in  the  following  basic  manner: 


Commands 


Reference 


Figure  15-15:  Simplified  Attitude  Control  System 
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15.5.1.2  Requirements  Definition 


As  put  forth  in  the  Task  Statement  provided  by  the  chief  decision  maker  (CDM), 
the  spacecraft  should  be  able  to  support  four  types  of  sensor  payloads:  electro-optical, 
infrared,  laser  designators,  and  synthetic  aperture  radar,  and  it  should  be  able  to  support 
one-meter  resolution  imagery  during  an  overhead  pass.  These  mission  support 
requirements  typically  drive  the  following  spacecraft  system  performance  requirements 
tied  to  ADCS  performance  requirements  (Eterno,  1992:343): 

•  Pointing  reference:  Earth-pointing  vs.  Sun-pointing  vs.  Inertial-pointing 

•  Pointing  range:  Angular  range  over  which  the  spacecraft  must  be  able  to  orient  itself 
with  respect  to  the  reference 

•  Pointing  accuracy:  Accuracy  in  which  the  spacecraft  can  be  controlled  to  point  in  a 
specified  direction 

•  Pointing  knowledge:  Accurately  that  the  attitude  sensors  determine  pointing  angles 
and  angular  rates 

•  Pointing  stability: 

•  Jitter:  Maximum  allowable  short-term,  high-frequency  motion  the  payload  can 
tolerate  and  still  perform  it's  mission 

•  Drift:  Maximum  allowable  limit  tolerable  on  slow,  low-frequency  angular 
motion 

•  Settling  time:  Time  allowable  for  the  spacecraft  to  recover  and  stabilize  from 
maneuvers  and  other  pointing  disturbances 

•  Slew  rate:  Speed  at  which  the  spacecraft  must  be  able  to  repoint  from  one  direction  to 
another 
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Sensor  selection  is  driven  primarily  by  pointing  reference,  knowledge,  and  accuracy 
requirements.  Actuator  selection  will  be  driven  primarily  by  pointing  range,  stability,  and 
slew  rate  requirements.  As  previously  mentioned,  care  must  be  taken  so  that  constraints 
affecting  other  subsystems  (for  example,  structural  limitations)  are  not  violated. 

All  requirements  are  ultimately  traceable  to  the  objectives  set  down  in  the  Value 
System  Design  (VSD).  The  ADCS  is  affected  by  the  fundamental  VSD  objectives 
"Maximize  Tactical  Responsiveness"  and  "Maximize  the  Mission  Utility".  Specifically, 
under  "Maximize  Tactical  Responsiveness"  attitude  determination  and  control 
requirements  are  driven  by  "Maximize  Capability  for  Tactical  Maneuvers",  as  measured  by 
slew  rate,  while  "Maximize  Pointing  Accuracy"  (a  sub-value  of  "Maximize  the  Mission 
Utility")  drives  all  other  pointing  requirements  (knowledge,  stability,  etc.). 

15.5.1.3  Design  and  Modeling  Process 

The  fundamental  ADCS  design  process  used  was  the  process  developed  by  Etemo, 
Zermuehlen,  and  Zimbelman  for  the  "Space  Mission  Analysis  and  Design"  text  (SMAD). 
As  this  process  is  useful  for  estimating  spacecraft  design  specifications,  it  would  need  to 
be  refined  as  the  design  evolves  in  order  to  incorporate  more  detail  and  greater  accuracy. 
The  actual  mathematical  modeling  was  done  in  a  MATLAB  environment  using  the 
equations  provided  by  SMAD. 

15.5.1.3.1  Control  Modes 

The  first  step  in  designing  an  ADCS  was  to  define  the  different  control  modes 
during  the  mission.  These  were  (1)  Orbit  Insertion,  (2)  Initial  Attitude  Acquisition,  (3) 
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Normal,  (4)  Slew,  (5)  Contingency/Safe,  and  (6)  Special.  Orbit  Insertion  is  the  period  in 
which  the  spacecraft  is  brought  into  it's  operational  orbit,  including  the  boost  phase.  Initial 
Attitude  Acquisition  begins  after  Orbit  Insertion.  During  this  phase,  the  spacecraft  takes 
it's  initial  attitude  measurements  and  uses  them  to  stabilize  itself.  The  Normal  mode  is  the 
spacecraft's  nominal,  operational  attitude  mode,  and  is  used  for  the  vast  majority  of  the 
mission  duration.  Slewing  mode  is  simply  the  control  mode  in  which  the  spacecraft 
performs  repointing  maneuvers.  Contingency/Safe  mode  is  used  in  emergencies,  such  as  if 
Normal  control  mode  is  disabled,  and  usually  involves  the  satellite  orienting  itself  so  that 
(a)  the  payload  is  protected,  (b)  the  solar  cells  (if  any)  are  positioned  so  that  they  receive 
the  most  sunlight,  and  (c)  shutting  down  all  non-critical  functions  and  awaiting 
instructions  from  the  ground  station.  The  Special  control  mode  can  be  defined  as  any 
mode  not  encompassed  by  the  others.  In  this  case,  it  will  refer  to  when  the  satellite  is 
configured  for  orbital  altitude  and  inclination  changes  (Etemo,  1992:343).  The 
requirements  of  each  mode  must  be  taken  into  consideration  when  selecting  ADCS 
hardware. 

During  Orbit  Insertion,  tradable  options  were  (a)  no  active  spacecraft  control,  (2) 
simple  spin  stabilization,  and  (3)  full  spacecraft  control  using  thrusters.  In  order  to  keep 
operations  as  simple  as  possible  in  keeping  with  a  "tactical"  mission,  it  was  decided  that 
the  spacecraft  will  use  no  active  control  during  orbit  insertion  but  will  rely  on  the  booster 
for  accurate  and  direct  insertion  into  low-Earth  orbit.  Slight  orbital  insertion  errors  made 
by  the  booster  can  be  corrected  with  Modsat's  onboard  Propulsion  system.  Initial  Attitude 
Acquisition  can  be  determined  by  the  satellite's  on-board  sensor  suite.  Because  this  is 
intended  to  be  a  low-Earth  orbiting  spacecraft,  an  Earth  sensor  seems  ideal  for  this  control 
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mode.  The  Earth  sensor  was  selected  because  it  can  provide  reasonable  accuracy  ( <  1 
degree)  (Etemo,  1992:360)  and  is  not  vulnerable  to  eclipses  as  is  a  Sun  sensor.  Star 
sensors  were  not  appropriate  because  they  take  time  to  accurately  lock  onto  their  targets. 
Often,  at  booster  separation,  some  kind  of  rotational  motion  (i.e.  "tip-off”)  is  imparted  to 
the  spacecraft.  In  such  a  case,  an  IMU  is  useful  because  it  can  directly  and  accurately 
measure  a  satellite's  rotational  and  translational  rates.  Control  torque  during  Initial 
Attitude  Acquisition  can  best  be  provided  by  thrusters.  Although  not  useful  for  fine 
control,  they  can  provide  more  than  enough  torque  quickly  enough  to  stabilize  the 
spacecraft,  in  addition,  fine  control  is  not  needed  at  this  point.  The  hardware  required  for 
Normal  mode  can  be  any  combination  of  sensors  and  actuators  that  meets  the  satellite's 
general  pointing  requirements.  As  long  as  slewing  rate  requirements  are  met,  Slew  mode 
can  also  use  any  combination  of  hardware.  Contingency/Safe  mode  will  use  the  same 
hardware  as  the  Initial  Attitude  Acquisition  control  mode.  Finally,  during  the  Special 
mode,  IMUs  and  thrusters  should  be  able  to  provide  reliable,  accurate  control  during 
altitude  and  inclination  changes. 

15.5.1.3.2  Control  Method 

The  next  step  in  the  ADCS  design  process  is  selecting  the  particular  type  of 
attitude  control  methods.  Options  include  gravity-gradient,  magnetic,  pure-spin,  dual-spin, 
one-axis  bias  momentum,  and  three-axis  stabilization  (Etemo,  1992:346).  Since  this 
decision  essentially  determined  what  kind  of  spacecraft  was  to  be  designed,  it  was  decided 
at  the  system  level  to  use  a  three-axis  stabilized  scheme.  The  primary  reason  behind  this 
decision  is  gravity-gradient  and  magnetic  control  modes,  while  the  simplest  mechanically, 
do  not  provide  the  kind  of  fine  pointing  accuracy  and  control  required  by  the  proposed 
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payloads  (gravity-gradient  ~  5  deg,  magnetic  ~5  deg)  (Etemo,  1992:346).  Furthermore, 
both  methods  provide  control  on  only  two  axes,  unacceptable  for  the  type  of  payloads 
envisioned  for  this  satellite  bus.  Finally,  gravity-gradient  and  magnetic  control  modes  are 
subject  to  irregularities  due  to  lack  of  detailed  knowledge  of  the  Earth's  gravitational  and 
magnetic  fields,  respectively.  A  spinning  satellite  was  ruled  out  because  it  only  provides 
control  on  two  axes. 

15.5.1.3.3  Disturbance  Environment 

The  next  step  in  the  SMAD  design  process  is  to  quantify  the  disturbance 
environment  due  to  natural  occurrences.  There  are  four  significant  sources  of  natural 
disturbance  torques:  (1)  the  Earth's  gravity  (gravity-gradient  disturbances),  (2)  solar 
radiation,  (3)  Earth's  magnetic  field,  and  (4)  aerodynamic  forces.  (Etemo,  1992:353)  Each 
is  dominant  at  different  orbits  and  under  varying  circumstances.  Gravity-gradient  effects 
are  present  at  all  orbits,  but  decrease  with  increasing  orbital  altitude.  Its  effects  were 
estimated  by  the  following  relationship  (Etemo,  1992:353): 

T,  si"(2«)  (Eqn  15-2) 

Tg  =  max  gravity  torque  (N*m) 
p  =  Earth's  gravity  constant  (3.986  x  1014  mVsec^) 

R  =  orbit  perigee  (meters) 

0  =  max  deviation  of  spacecraft  z-axis  from  nadir  vector  (radians);  assumed  0  =  nlA  for 
max  torque  calculations 

Imin,  Imax  =  maximum  and  minimum  moments  of  inertia  (kg/m^) 

For  the  Earth-oriented  application  this  design  study  focuses  on,  gravity-gradient  torque  is 
generally  constant  over  an  orbit.  For  a  completely  symmetric  spacecraft,  gravity-gradient 
torques  are  nonexistent,  but  can  be  significant  for  spacecraft  with  long,  deployed 
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structures  such  as  booms.  The  disturbance  torque  due  to  pressure  from  solar  radiation  is 
estimated  by  the  following  (Etemo,  1992:353); 

=  y  4(1  +  4)  cos/(cp,  -  (Eqn  15-3) 

Tsp  =  max.  solar  radiation  pressure  torque  (N*m) 

Fs  =  solar  constant  (1358  wattsW) 
c  =  speed  of  light  (2.997  x  10*  m/sec) 

As  =  exposed  spacecraft  surface  area  (m^) 
q  =  overall  spacecraft  reflectance  (dimensionless,  estimated  at  0.6) 
i  =  angle  of  incidence  to  the  Sun  (assume  i  =  0  radians  for  max  effect) 

Cps  -  Cg  =  max.  distance  between  center  of  solar  pressure  and  center  of  gravity  (since  Cps 
and  Cg  were  not  well  characterized,  assumed  difference  is  one-half  the  length  of  satellite 
body) 


Torques  generated  by  the  effects  of  solar  pressure  are,  unlike  the  other  disturbances, 
generally  independent  of  orbital  altitude.  This  type  of  disturbance  torque  is  highly 
dependent  on  the  nature  of  the  surface  being  illuminated,  particularly  on  the  radiation 
absorbtivity  of  the  surface  (absorbent,  spectrally  reflective,  diffusely  reflective, 
transparent,  or  some  combination).  The  spacecraft's  orientation  with  respect  to  the  local 
sun  angle  also  plays  a  significant  role,  as  does  the  total  spacecraft  area  exposed  to  the  Sun, 
especially  if  extended  solar  panels  are  used.  Solar  torque  is  cyclic  in  nature,  varying  over 
the  course  of  an  orbit  and  nonexistent  during  an  eclipse  period.  Torques  caused  by  the 
Earth's  magnetic  field  are  dependent  on  the  spacecraft's  orbit  altitude  and  inclination.  The 
estimating  relationship  is  (Etemo,  1992:353): 

T;  =  ^  (Eqn  15-4) 


Tn,  =  max.  magnetic  torque  (N*m) 
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D  =  spacecraft's  residual  dipole  (assume  1  ampere-tum*m^) 

M  =  Earth's  magnetic  moment  (7.96  x  tesla*m^) 

R  =  orbit  perigee  (meters) 

The  Earth's  magnetic  field  is  stronger  at  low-Earth  orbits,  almost  nonexistent  at  higher 
orbits,  and  varies  greatly  with  orbit  inclination. 

The  final  external  source  of  disturbance  torque  is  due  to  aerodynamics.  It  is 
estimated  by  (Etemo,  1 992 : 3  5 3 ) : 


T.  =  Oi[pC,/lF’](c„  -  c,)  (Eqn  15-5) 

Ta=  aerodynamic  torque  (N*m) 
p  =  atmospheric  density  at  perigee  (kg/m^) 

Cd  =  spacecraft  drag  coefficient 

A  =  spacecraft  cross-sectional  area  in  direction  of  flight  (m^) 

V  =  spacecraft  velocity 

Cpa  -  Cg  =  difference  between  spacecraft  center  of  aerodynamic  pressure  and  center  of 
gravity  (m)  (since  Cpa  and  Cg  were  not  well  characterized,  assumed  difference  is  one-half 
the  length  of  satellite  body) 

Aerodynamic  torques  are  nonexistent  at  high  orbits,  but  can  completely  dominate 
all  other  disturbance  torques  at  low  orbits  as  indicated  in  Table  15-10.  Aerodynamic 
torques,  to  the  greatest  extent,  depend  on  the  shape  and  size  of  the  satellite  and  on  the 
atmospheric  density  at  a  given  orbit  altitude.  They  are  constant  over  the  course  of  an  orbit 
for  Earth-oriented  vehicles.  It  should  be  mentioned  that,  with  the  exception  of  gravity- 
gradient,  all  of  the  aforementioned  forces  vary  with  the  solar  cycle.  Selection  and  sizing  of 
the  actuators  primarily  depends  on  the  worst-case  disturbance  torques  the  spacecraft  is 
expected  to  encounter.  Other  sources  of  disturbance  torques  are  internal  to  the  spacecraft 
(center-of-gravity  uncertainties,  thruster  misalignments,  fuel  sloshing,  etc.)  and  can  be 
minimized  by  carefial  spacecraft  design  and  tight  manufacturing  tolerances. 
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Table  15-10:  Disturbance  Torques 


Source 

Lowest  (N*m) 

Highest  (N*m) 

Gravity-gradient 
Solar  pressure 
Earth  magnetic  field 
Aerodynamics 

1.6  X  10'® 

4.0x  10-® 

5.2  x  10'^ 
0.0017 

same 

3.1  X  10'^ 

same 

0.013 

These  calculations  assume  a  350km,  Sun-synchronous  orbit.  The  highest/lowest  values  are 
based  on  the  orientation  of  the  solar  panels  to  the  direction  of  flight.  If  they  are  facing  the 
direction  of  flight,  the  aerodynamic  loads  on  the  satellite  will  be  most  severe.  If  they  are 
orthogonal  to  the  direction  of  flight,  then  aerodynamic  loads  will  be  the  lowest.  Similarly, 
the  torque  due  to  solar  pressure  will  be  more  severe  depending  on  the  solar  panels' 
incident  angle  to  the  Sun. 

The  analysis  of  Modsat's  disturbance  environment  revealed  that  the  major  source 
of  disturbance  torques  will  be  due  to  aerodynamics.  Hence,  for  disturbance  rejection,  the 
ADCS  will  be  designed  to  counteract  aerodynamic  torques. 

15.5.1.3.4  Select  ADCS  Hardware 

15.5.1.3.4.1  Sensor  Selection 

The  next  step,  selecting  and  sizing  the  ADCS  hardware,  is  the  heart  of  the  ADCS 
design  process.  The  hardware  must  be  selected  in  conformance  with  system  performance 
requirements,  it  must  be  able  to  withstand  and  correct  for  disturbances,  and  at  the  same 
time  it  must  not  exceed  it's  size,  weight,  and  power  allocation.  When  considering  sensors, 
the  available  options  are  Sun  sensors.  Earth-horizon  sensors,  star  sensors,  magnetometers, 
and  IMUs.  Since  the  spacecraft  will  not  employ  magnetic  stabilization  techniques. 
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magnetometers  were  unnecessary.  It  was  decided  during  an  earlier  design  step  that  Earth 
sensors  and  IMUs  would  be  a  good  idea.  However,  IMUs  are  subject  to  "gyro-drift", 
meaning  they  tend  to  lose  accuracy  over  a  long  period  of  time,  and  must  be  periodically 
updated  and  corrected  using  information  from  other  sensors.  Earth  sensors  can  be  fairly 
accurate  (<  1  degree)  (Etemo,  1992:360)  but  may  not  be  accurate  enough  for  laser 
designators  and  other  extremely  high-accuracy  payloads.  There  are  Sun  sensors  available 
that  can  achieve  arc-second  accuracy  pointing  knowledge,  but  are  useless  during  eclipse 
periods,  which  occur  often  for  low-Earth  orbiting  spacecraft.  Star  sensors  can  provide  arc- 
second  attitude  knowledge  (Etemo,  1992:360).  They  are  fairly  simple  mechanically  and 
computationally  and  are  widely  available.  In  addition,  by  including  the  Sun's  stellar 
magnitude  in  it's  database,  they  can  theoretically  double  as  Sun  sensors.  Therefore, 

Modsat  will  use  a  star  sensor  to  meet  its  fine  attitude  knowledge  requirements.  Restating 
the  choices  made  for  Modsat's  ADCS  sensor  suite,  an  Earth  sensor,  star  sensor,  and  an 
EVtU  were  selected.  The  size,  weight,  power,  and  performance  of  the  selected  sensors  are 


listed  in  Table  15-11. 

Table  15-11;  Characteristics  of  Modsat  Sensor  Suite 


Sensor 

Model 

Performance 

Weight 

Power 

Supplier 

IMU 

YG9666B  Miniature  MU 

gyro  drift  rate 
=  0.02deg/hr 

3.45  kg 

33 

watts 

Honeywell 

Earth  sensor 

13-105  LightSat  Earth  Sensor 

accuracy 
=  0.04  degrees 

2.41  kg 

4  watts 

EDO 

(Barnes) 

Star  sensor 

CT-633  Stellar  Attitude  sensor 

accuracy 

=  10  arcsec 

2.49  kg 

10 

watts 

Ball 

Aerospace 
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15.5.1.3.4.2  Actuator  Selection 


When  selecting  an  actuator  suite,  the  choices  include  reaction  wheels,  momentum 
wheels,  control-moment  gyros  (CMGs),  electromagnetic  torquers,  and  thrusters  (Etemo, 
1992:355).  The  choice  of  actuators  was  determined  by  the  amount  of  torque  needed  to 
meet  attitude  stability  (itself  driven  by  disturbance  torques)  and  slewing  requirements. 
Electromagnetic  torquers,  while  simple  and  reliable,  cannot  generate  enough  torque  for 
rapid  slewing  and  momentum-dumping  operations  that  a  tactically-oriented  satellite  should 
have,  are  subject  to  uncertainties  in  the  Earth's  magnetic  field,  and  may  not  work  for  some 
orbits  and  inclinations,  particularly  over  the  Earth's  magnetic  poles.  Therefore,  they  will 
not  be  used. 

It  was  previously  determined  that  thrusters  would  be  useful  in  the  Initial  Attitude 
Acquisition  and  Special  control  modes.  Thrusters  can  provide  plenty  of  force  for  both 
rapid  slewing  and  momentum-dumping.  They  are  also  useful  for  coarse  attitude  control. 
This  leaves  either  reaction  wheels,  momentum  wheels,  and/or  CMGs  for  use  in  fine 
attitude  control  and  resisting  disturbance  torques.  CMGs  operate  by  moving  gimbals 
attached  to  a  wheel  spinning  at  a  constant  rate.  The  wheel  has  an  angular  momentum 
vector  along  one  axis,  the  gimbal  is  turned  about  a  second  axis  orthogonal  to  the  first,  and 
the  satellite  moves  around  the  third  orthogonal  axis.  CMGs  are  capable  of  generating  large 
amounts  of  torque  and  can  provide  rapid,  precise  maneuvering  for  spacecraft.  However, 
they  tend  to  be  heavy,  expensive,  and  require  a  lot  of  power.  They  also  require  a  fairly 
complex  control  law  to  operate  (Etemo,  1992:356).  Reaction  and  momentum  wheels  are 
essentially  high-inertia  rotors  that  rotate  about  a  fixed  axis.  Momentum  wheels  turn  in  one 
direction  only  and  have  a  nominal  spin  rate  greater  than  zero,  thus  providing  some 
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inherent  resistance  to  disturbance  torques  based  on  how  large  the  wheel's  angular 
momentum  vector  is.  The  rotor  speed  can  be  adjusted  to  compensate  for  disturbing 
torques.  Reaction  wheels  have  a  nominal  rotor  speed  of  zero  and  can  turn  in  either 
direction  in  response  to  disturbance  torques.  By  turning  the  wheel,  the  equal  and  opposite 
reaction  of  the  turning  motor  on  the  spacecraft  rotates  the  spacecraft  in  the  opposite 
direction.  Reaction  and  momentum  wheels  don't  provide  the  sheer  torque  capacity  of 
CMGs,  but  are  widely  available  and  come  in  a  variety  of  sizes.  They  tend  not  to  require  as 
much  power  as  a  CMG,  either  (Etemo,  1992:355).  For  the  purposes  of  resisting 
disturbance  torques  and  for  low-speed  slewing,  reaction  and/or  momentum  wheels  are 
adequate,  therefore  either  reaction  wheels  or  momentum  wheels  will  be  used. 

The  pointing  accuracy  of  reaction  wheels  depends  on  the  design  of  the  control 
logic  (how  finely  can  the  wheels'  rotation  be  controlled?)  and  the  wheels'  manufacturing 
quality  (for  example,  are  the  wheels  subject  to  "sticking"  when  started  up  or  operating  at 
slow  speeds?).  A  momentum  wheel's  accuracy  depends  upon  it's  ability  to  generate  an 
angular  momentum  vector  large  enough  to  resist  disturbances  via  the  gyroscopic 
"stiffiiess"  a  large  angular  momentum  vector  inherently  provides.  The  appropriate  size  can 
be  estimated  by  considering  the  largest  expected  disturbance  a  wheel  must  be  able  to 
counteract,  calculating  the  slew  torque  a  wheel  must  generate  in  order  to  meet  slewing 
requirements,  and  the  amount  of  angular  momentum  a  wheel  must  be  able  to  store  based 
on  accumulated  disturbance  torques  (Etemo,  1992:357). 

The  largest  expected  disturbance  a  wheel  is  expected  to  be  able  to  counteract  is 
equal  to  the  largest  torque  imposed  on  the  satellite  from  the  environment.  From  Table  15- 
10,  the  largest  expected  torque  is  0.01318  N*m. 
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The  slew  capacity  of  a  reaction  wheel/momentum  wheel  was  estimated  by  using 


(Etemo,  1992:357); 


7’  =  4^-^  '  (Eqn  15-6) 

Tsiew  =  slew  torque  (N*m) 

0  =  max  angle  satellite  must  be  able  to  slew  through  (radians) 

I  =  largest  value  of  spacecraft's  inertia  matrix  (kg*m^) 
t  =  allowable  time  in  which  satellite  must  complete  the  slew  (seconds). 

The  maximum  angle  and  time  was  selected  to  be  180  degrees  and  36  seconds,  thus 

creating  an  slew  rate  requirement  of  5  degrees  per  second.  Sizing  reaction  wheels  for 

angular  momentum  storage  was  estimated  by  the  following  equation  (Etemo,  1992:357): 

H=T^P  (Eqn  15-7) 

H  =  wheel  angular  momentum  storage  capacity  per  orbit  (N*m*s) 

Td  =  disturbance  torque  (N*m) 

P  =  orbit  period  (seconds) 

This  assumes  that  the  wheels  will  be  desaturated  (i.e.  "momentum-dumped")  an  average  of 
once  per  orbit.  If  more  frequent  desaturation  is  allowed,  the  wheels  can  be  made  smaller. 

If  less  frequent  desaturation  is  desired,  the  wheels  must  be  made  larger. 

To  determine  the  amount  of  angular  momentum  a  momentum  wheel  must  generate 
to  resist  disturbances  and  maintain  the  required  pointing  accuracy  (Etemo,  1992:357); 

H  =  r—  (Eqn  15-8) 

H  =  angular  momentum  (N*m*s) 

T  =  disturbance  torque  (N*m) 

P  =  orbit  period  (seconds) 

0a  =  pointing  accuracy  (radians).  Assume  pointing  accuracy  equal  to  best  pointing 
knowledge  provided  by  sensors  (10  arc-seconds) 
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Table  15-12  shows  the  required  slew  torque  and  angular  momentum  storage  for 


both  reaction  wheels  and  momentum  wheels. 


Table  15-12:  Required  Slewing  Torque  and  Angular  Momentum  Storage  Capacity 


Actuator 

Required  Slewing  Torque 
(N*m) 

Storage  Capacity  (N*m*sec) 

Reaction  Wheels 

Momentum  Wheels 

0.0009  N*m 

0.0009  N*m 

9.34  N*m*s  to  72.38  N*m*s 

44590  N*m*s  to  345600 
N*m*s 

The  actual  storage  requirement  is  highly  dependent  on  the  orientation  of  the  solar  panels 
over  the  course  of  an  orbit.  It  is  unlikely  that  the  satellite  would  be  flown  with  the  solar 
panels  facing  the  direction  of  flight  for  the  entire  orbit  (to  do  so  may  cause  unacceptable 
degradation  in  the  solar  arrays),  so  the  actual  amount  of  required  angular  momentum 
storage  should  be  much  less  than  the  maximum.  Note  that  the  momentum  wheel  storage 
requirement  is  extremely  large  (due  to  the  large  disturbances  caused  by  aerodynamics  in  a 
350  km  orbit),  hence  for  low  orbits,  momentum  wheels  are  not  a  good  choice.  Reaction 
wheels  should  be  used  instead.  Four  reaction  wheels,  arranged  in  a  pyramid,  will  be  used. 
This  type  of  arrangement  requires  that  at  least  two  wheels  be  actuated  in  order  to  rotate 
on  a  single  axis.  A  simpler  method  would  have  been  to  align  one  wheel  on  each  of  the 
satellite's  principal  axes  (hence  eliminating  the  need  for  a  fourth  wheel),  but  by  using  a 
four-wheel  configuration  the  wheels  can  be  made  smaller,  and  the  combined  effect  of 
actuating  two  wheels  at  a  time  can  generate  as  much  or  more  angular  momentum  as  with 
can  be  generated  with  one  larger  wheel.  Table  15-13  contains  a  description  of  the  reaction 
wheels  selected. 
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Table  15-13:  Characteristics  of  Selected  Reaction  Wheels 


Name 

T-Reaction  Wheel  Type  B 

Manufacturer 

Ithaco 

Angular  momentum  storage  (each 
wheel) 

16.6  N*m*s 

Maximum  torque  (each  wheel) 

0.04  N*m 

Size 

25.5  cm  diameter,  9.0  cm  height 

Mass 

5.1  kg 

Power 

6.5  W  (nominal),  17.5  W(peak) 

Reaction  wheels  must  be  periodically  desaturated,  that  is,  the  stored  angular 
momentum  must  be  disposed  of.  To  do  this,  thrusters  will  be  used.  Thrusters  must  be 
sized  so  that,  in  addition  to  being  able  to  provide  translational  motion  to  the  spacecraft, 
they  can  provide  enough  torque  to  hold  the  spacecraft  steady  while  the  wheels  are 
desaturated,  and  to  skew  the  spacecraft  if  necessary.  The  equation  for  sizing  a  thruster  to 
meet  slew  requirements  of  a  reaction  wheel-driven  spacecraft  is  (Eterno,  1992:358): 

F  - —{slew rate)  (Eqn  15-9) 

Lt 

F  ==  thrust  force  needed  to  meet  slew  requirement  (N) 

I  =  max.  moment  of  inertia  (kg*m^) 

L  =  thruster  moment  arm  (m) 

t  =  time  required  to  accelerate  from  zero  to  5  degrees/sec  in  3  seconds 

For  Modsat,  the  required  force  level  is  approximately  0.01  N,  well  within  the  capability  of 

most  thrusters. 

The  estimated  thruster  size  to  dump  momentum  is  given  by  (Eterno,  1992:359): 

F  =  —  (Eqn  15-10) 

Lt 

F  =  force  level  required  (N) 

H  =  stored  angular  momentum  (N*m*s) 
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L  =  thruster  moment  arm  (m) 
t  =  thruster  bum  time  (sec) 

For  Modsat,  allowing  two  minutes  to  desaturate  the  reaction  wheels,  the  required  thruster 
size  is  1 . 1  N.  If  more  time  is  allotted  for  momentum  dumping,  thmster  size  can  be 
decreased.  If  less  time  is  required,  thmster  size  must  be  increased.  The  thmster  suite 
ultimately  selected  for  Modsat  included  six  22.4  N  thmsters  (see  section  15.5.2),  which 
allows  momentum  to  de  dumped  in  less  than  six  seconds  per  wheel. 

15.5.1.3.5  Control  Algorithms 

The  design  of  the  control  algorithms  was  beyond  the  scope  of  this  project,  and  not 
relevant  to  any  of  the  decisions  made. 

15.5.2  Propulsion 

Space  propulsion  systems  perform  three  major  functions.  They  lift  the  launch 
vehicle  and  payload  from  the  launch  pad  and  place  the  payload  into  low-Earth  orbit 
(LEO).  They  transfer  loads  from  low-Earth  orbits  into  higher  orbit  or  into  trajectories  for 
planetary  encounters.  Finally,  they  provide  thmst  for  attitude  control  and  orbit  corrections. 

Selection  of  the  launch  vehicle  has  been  previously  discussed,  and  Modsat  will  not 
require  propulsion  to  transfer  orbits,  due  to  its  LEO  requirement.  Therefore,  this  section 
of  the  report  will  focus  on  the  third  major  function  listed  above,  that  of  an  on-board 
spacecraft  propulsion  subsystem. 

The  main  objective  of  this  propulsion  subsystem  design  study  was  to  provide  a 
cost-effective  system,  in  accordance  with  the  requirements  and  objectives  of  the  overall 

study.  Since  a  major  emphasis  has  been  placed  on  the  use  of  competitively  priced,  proven 
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technology,  the  team  did  not  set  out  to  design  new  concepts  in  spacecraft  propulsion. 
Instead,  the  design  effort  was  limited  to  making  use  of  currently  available,  off-the-shelf 
technology. 


15.5.2.1  Propulsion  Functions 

The  Modsat  propulsion  subsystem  performs  the  following  functions: 

•  Orbital  corrections. 

•  Tactical  re-deployment. 

•  Acquisition  of  Sun,  Earth,  or  star. 

•  On-orbit  back-up  mode  control  with  3-axis  stabilization. 

•  Momentum  management. 

•  3 -axis  control  during  AV. 

Note  that  during  normal  operations  attitude  control  will  be  primarily  performed  by 
the  Attitude  Determination  and  Control  Subsystem  (ADCS).  The  propulsion  system 
serves  as  a  backup  option  in  case  the  ADCS  is  off-line. 

15.5.2.2  Propellant  and  AV  Budget  and  Thrust  Levels 

Most  of  the  necessary  calculations  are  discussed  in  the  ADCS  subsystem  study, 
section  15.5.1.  Total  propellant  mass  is  calculated  with  respect  to  the  chosen  propellant 
and  the  demanded  AV  capability.  Thruster  size  depends  on  the  maximum  required  amount 
of  acceleration. 


192 


15.5.2.3  Propulsion  System  Options 

There  are  three  candidate  propulsion  options  for  this  study:  cold  gas,  liquid  mono¬ 
propellant,  and  liquid  bi-propellant.  The  comparisons  among  them  are  shown  in  Table  15- 
14  and  Table  15-15.  Although  cold  gas  has  attractive  features  such  as  simplicity,  high 
reliability  and  low  cost,  its  limited  specific  impulse,  low  thrust  ratio,  and  heavy  weight  led 
to  its  elimination  fi'om  consideration.  The  remaining  material  focuses  on  the  liquid  mono¬ 
propellant  and  bi-propellant  options. 

Spacecraft  propulsion  systems  have  five  major  components: 

•  Propellant :  The  fuel  of  the  propulsion  system. 

•  Fuel  feed  systems:  Feeds  the  propellant  distribution  system  with  fiiel  on  demand. 

•  Storage  Systems  (tanks):  Propellant  storage. 

•  Engine:  Thruster. 

•  Coimections:  System  that  connects  the  other  components  and  manages  fuel 
distribution  through  the  use  of  pipes,  vanes,  regulators  etc.  The  design  of  a  specific 
coimection  system  is  beyond  the  scope  of  this  preliminary  design  study.  Rather,  all 
candidate  propulsion  system  solutions  will  account  for  connections  as  a  percentage  of 
cost,  weight ,  volume  etc. 
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Table  15-14:  Candidate  Propulsion  Options 


Type 

Energy 

Advantages 

Disadvantages 

Cold  Gas 

High  pressure 

j 

1.  Simple  hardware. 

2. High  reliability. 

3.  Low  cost. 

4. Perfect  when  the 
exhaust  temperature 
is  important  for 
satellite. 

1. Very  low 
performance(e.g. 
specific  impulse  and 
thrust). 

2.  The  heaviest  of  all 
systems  for  given 
performance  level. 

Liquid  Mono- 

Exothermic 

l.Simplerthanbi- 

1  .Lower 

propellant 

decomposition 

propellant  systems. 

2. More  reliable  than 
bi-propellant  systems. 

3.  Lower  cost  than  bi¬ 
propellant  systems. 

performance(e.g. 
specific  impulse  and 
thrust)  than  bi¬ 
propellant  systems. 

2. Higher  weight  than 
bi-propellant. 

Liquid  Bi-propellant 

Chemical 

reaction 

1  .Higher  performance 
(e.g.  specific  impulse 
and  thrust). 

2.  MMH  and  UDMH^ 
are  storable. 

1. Cyrogenic  material 
handling  difficulty. 

2.  Some  propellants  are 
dangerous. 

3.  Complicated  systems 

Source:  Sackheim  and  others,  1992:645-646 


Table  15-15:  Other  Propulsion  Options 


Type 

Description 

SOLID 

One  shot  propulsion;  usually  used  for  orbit  insertion  in  launch  systems 

LIQUID 

Water  Electrolysis 

Complicated;  not  developed  for  commercial  use;  high  power 
requirement 

Hybrid 

Bulkier  than  solid  systems;  usually  used  for  orbit  insertion  and  orbit 
maintenance,  not  for  attitude  control 

ELECTRIC 

Electrothermal 

High  power  requirement;  complicated;  some  systems  have  high 

Electrostatic 

Electromagnetic 

development  risk 

Source:  Sackheim  and  others,  1992:645-646 


^  Monomethyl  Hydrazine  (MMO)  and  Unsymmetrical  Dimethylhydrazine  (UDMH) 
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15.5.2.3.1  Propellant 


The  most  common  liquid  propellant  is  hydrazine,  which  is  flight  proven  and 
experienced.  All  its  properties,  hazards,  safety  facts,  storage  conditions,  etc.  are  well 
known.  Six  different  blends  of  mono-propellants  (Table  15-16)  and  five  different 
hydrazine  bi-propellant  combinations  (Table  15-17)  were  examined  as  alternative  options 
and  were  taken  into  consideration  in  all  calculations  to  generate  alternative  propulsion 
options. 

A  mono-propellant  contains  an  oxidizing  agent  and  combustible  matter  in  a  single 
substance.  It  may  be  a  mixture  of  several  compounds  or  it  may  be  a  homogeneous 
material,  such  as  nitromethane  or  hydrazine.  Mono-propellants  are  stable  at  ordinary 
atmospheric  conditions  but  decompose  and  yield  hot  combustion  gases  when  heated  or 
catalyzed. 


Table  15-16:  Mono-propellant  Blends 


Freezing  Point 
(K) 

Composition 
WT.  -  % 

HN  H2O 

N2H4 

Density 

(gm/cc) 

Decomposition 

Temperature 

(K) 

Isp 

(sec) 

274.67 

00 

00 

100 

1.004 

1,344 

245.9 

252.45 

18 

8 

74 

1.080 

1,422 

243.0 

239.12 

20 

12 

68 

1.093 

1,360 

236.2 

254.67 

24 

00 

76 

1.110 

1,622 

263.8 

239.12 

24 

09 

67 

1.109 

1,510 

245.8 

219.12 

25 

17 

58 

1.120 

1,300 

229.9 

Source:  Hydrazine  Handbook,  1995:2-18 


A  bi-propellant  rocket  unit  has  two  separate  propellants,  an  oxidizer  and  a  fuel. 
They  are  stored  separately  and  are  not  mixed  outside  the  combustion  chamber.  The 
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majority  of  liquid  propellant  rockets  have  been  manufactured  for  bi-propellant 
applications. 


Table  15-17:  Bi-propellant  Combinations 


Combination 

Oxidizer  Fuel 

Mixture  Ratio 

By  Mass  By  Volume 

Density 

(gm/cc) 

Chamber 

Temperature 

(K) 

Isp 

(sec) 

Oxygen 

Hydrazine 

1.07 

3027 

313 

Oxygen 

-  UDMH 

1.65 

1.14 

0.98 

3321 

310 

Fluorine 

Hydrazine 

2.30 

1.54 

1.31 

4408 

363 

Nitrogen 

_  Hydrazine 

1.34 

0..75 

1.22 

2977 

292 

Tetroxide 

Nitrogen 

_  50%  Hydrazine 

2.00 

1.24 

1.21 

3088 

288 

Tetroxide 

50%  UDMH 

Source:  Dueber  and  McKnigl 

It,  1993:139 

A  cryogenic  propellant  is  liquefied  gas  at  low  temperature,  such  as  liquid  oxygen 
( — 147°C)  or  liquid  hydrogen  ( — 253°C).  Provisions  for  venting  the  storage  tank  and 
minimizing  vaporization  losses  are  necessary  with  this  type. 

Storable  propellants  (e.g.,  nitric  acid  or  gasoline)  are  liquid  at  ambient  temperature 
and  can  be  stored  for  long  periods  in  sealed  tanks.  Space-storable  propellants  are  liquid  in 
the  temperatures  of  space;  this  storability  depends  on  the  specific  tank  design,  thermal 
conditions  and  tank  pressure. 

The  propellant  mixture  ratio  is  the  ratio  of  oxidizer  to  fuel  in  the  reaction  mixture. 


15.5.2.3.2  Fuel  Feed  Systems 

The  following  material  is  based  largely  on  the  work  of  Sackheim,  Wolf  and  Zaffan 
(1992:  654)  and  Sutton  (1992:  211-230).  The  selection  of  a  particular  feed  system  and  its 
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components  is  governed  primarily  by  the  following:  the  application  of  the  rocket;  its  size; 
type  and  amount  of  propellant;  required  thrust;  flight  program  and  duration;  number  or 
type  of  thrust  chambers;  past  experience;  mission  velocity;  and  in  general  the  need  for 
simplicity  of  design,  ease  of  manufacturing,  reliability  of  operation,  and  minimum  weight. 

In  general,  a  pressure  feed  system  delivers  superior  performance  over  a  turbo¬ 
pump  system,  when  the  total  impulse  or  the  mass  of  propellant  is  relatively  low,  the 
chamber  pressure  is  low,  the  engine  thrust-to-weight  ratio  is  low  (usually  less  then  0.6), 
and  when  there  are  repeated  short-duration  thrust  pulses.  The  heavy- walled  tanks  for  the 
propellant  and  the  pressurizing  gas  usually  constitute  the  major  weight  of  the  engine 
system.  In  turbo-pump  feed  systems  the  propellant  tank  pressures  are  much  lower  (by  a 
factor  of  10  to  40);  thus,  the  tank  weights  are  much  lower  (again  by  a  factor  of  10  to  40). 
Turbo-pump  systems  usually  deliver  superior  vehicle  performance  when  the  total  impulse 
is  large  (higher  AV)  and  the  chamber  pressure  is  high. 

The  pressurized  feed  system  can  be  relatively  simple,  such  as  for  a  single¬ 
operation,  factory-preloaded,  simple  unit  (with  burst  diaphragms  replacing  some  of  the 
valves).  On  the  other  hand,  pressurized  feed  systems  can  also  be  quite  complex,  as  with 
multiple  re-startable  thrusters  or  reusable  systems. 

System  options  are: 

•  Pressure-fed  Systems:  Blow-down  or  regulated  systems 

-  Used  for  rockets  that  deliver  low  (up  to  10  N)  or  moderate  (10  N  to  200  N) 
levels  of  thrust  and  total  impulse. 

-  The  overall  system  weight  is  reduced  due  to  the  simplicity  of  this  system. 
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-  They  are  reliable,  due  to  their  simplicity. 

•  Pump-fed  Systems:  Piston  or  turbo-pump,  which  can  be  driven  by  turbines,  gas 
pressure  intensifiers,  or  directly  by  electric  motors. 

-  For  large  total  impulse  and  thrust  requirements,  the  propellant  tanks  may 
become  prohibitively  large  and  heavy. 

-  Heavier  than  pressure-fed  systems. 

-  Definitely  lighter  for  applications  using  high  thrust  and  longer  total  bum,  such 
as  launch  vehicles. 

The  choice  of  fuel  feed  system  type  was  influenced  heavily  by  the  fact  that  the 
bus  design  must  support  small  tactical  mission  modules  during  a  relatively  short  mission 
lifetime,  and  that  the  bus  will  be  launched  on  the  Pegasus  Launch  Vehicle.  Given  these 
considerations,  a  pressure  feed  system  is  a  reasonable  choice,  for  the  following  reasons: 

•  The  propulsion  system  will  be  used  for  altitude  maintenance,  momentum  dumping  and 
inclination  change  (for  tactical  maneuvers).  There  is  no  known  need  for  high  thmst 
and  high  bum  times. 

•  The  bus  system  has  been  designed  for  one  lifetime;  reusability  is  not  considered. 

•  The  bus  must  support  a  small  satellite.  Weight  and  volume  considerations  were  very 
influential  during  design.  Thus,  the  small  and  light  pressure-fed  systems  are 
appropriate. 

One  of  the  simplest  and  most  common  means  of  pressurizing  the  propellants  is  to 
force  them  out  of  their  respective  tanks  by  displacing  them  with  high-pressure  gas.  This 
gas  is  fed  into  the  propellant  tanks  at  a  controlled  pressure,  thereby  giving  a  controlled 
propellant  discharge.  Because  of  their  relative  simplicity,  rocket  engines  with  pressurized 
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feed  systems  tend  to  be  very  reliable.  With  mono-propellants,  the  gas  pressure  feed  system 
becomes  simpler  than  for  bi-propellants,  since  the  number  of  pipes,  valves,  and  tanks  is 
reduced. 

Blow-down  and  regulated  pressure  systems  were  considered  as  viable  options 
throughout  the  design  effort;  see  Figure  15-16. 


Typical  Pressure 
Blowdown  Ratio: 
300  to  400  psia 
(2  MPa  -  2.76  Mpa) 
at  the  beginning  to 
-lOOpsiaCe.SPSkPa) 
end  of  the  life. 


Figure  15-16:  Gas  Pressure  Systems 

Source:  Sackheim  and  others,  1992:654 

15.5.2.3.3  Storage  Systems 

Liquid  storage  systems  need  to  manage  the  liquid  propellant  under  zero  gravity  to 
ensure  that  neither  gas  nor  vapor  is  expelled  from  the  tank.  Options  for  liquid  propellant 
management  include: 

•  Artificial  gravity,  induced  by  spinning  spacecraft.  This  can  be  ruled  out,  since  Modsat 
will  be  3 -axis  stabilized. 
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•  Inducing  propellant  burn  by  the  use  of  a  small  rocket. 

•  Positive  expulsion  systems:  use  an  active  element  (a  bladder,  piston,  or  bellows)  to 
separate  the  pressurant  gas  from  the  liquid  propellants  under  all  dynamic  conditions, 
and  to  force  the  liquid  from  the  tank  into  the  feed  lines  on  demand. 

•  Surface  tension  systems;  passively  manage  the  propellants  in  a  zero  gravity 
environment  by  using  vanes,  screens,  or  sponges  to  wick  the  propellant  into  the 
propellant  tank  outlets.  The  pressurizing  gas  bubble  is  always  kept  in  the  center  of  the 
tank.  All  of  these  devices  rely  on  surface  tension  forces  to  separate  liquids  from  gases. 

•  Piston  expulsion  devices:  permit  the  center  of  gravity  (CG)  to  be  accurately  controlled 
and  its  location  to  be  known.  This  is  important  in  rockets  with  high  side  accelerations 
such  as  antiaircraft  missiles  or  space  defense  missiles,  where  the  thrust  vector  needs  to 
go  through  the  CG.  If  the  CG  is  not  well  known,  unpredictable  turning  moments  may 
be  imposed  on  the  vehicle.  A  piston  also  prevents  sloshing  or  vortexing. 

The  positive  expulsion  system  is  appropriate  for  Modsat,  for  the  following  reasons: 

•  The  ADCS  requirement  for  accurate  control. 

•  They  are  flight  proven,  off-the-shelf  designs. 

•  They  have  good  expulsion  efficiency. 

•  They  are  lighter  than  piston  expulsion  systems. 

Among  positive  expulsion  systems  there  are  several  alternatives,  but  at  this  level  of 

design  they  will  not  be  considered.  It  is  assumed  that  the  most  common  diaphragm 

will  be  used  as  a  storage  system.  (Sackheim  and  others,  1992:655;  Sutton,  1992:216-223). 
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15.5.2.3.4  Engine  (Thrnster) 


Depending  upon  specific  mission  requirements,  a  spacecraft  can  employ  from  a 
few  thrusters  to  more  than  30  thrust  units.  These  thrusters  may  generate  long  steady-state 
bums  or  short  pulses  of  several  milliseconds,  each  used  to  control  maneuvers,  maintain 
orbit,  control  attitude  or  manage  momentum. 

Two  primary  considerations  in  choosing  thrusters  are  operating  life  (total  number 
of  pulses),  thmst,  total  impulse,  and  time  of  steady  state  firing  (sec). 

It  was  not  the  intent  of  this  study  to  design  new  thmsters.  The  approach  was  to 
examine  the  overall  objectives  for  the  Modsat  bus  and  to  select  the  appropriate  engine 
type  and  number  from  the  available  off-the-shelf  items. 

15.5.2.4  Designing  a  Propulsion  System 

To  design  a  propulsion  system,  one  must  analyze  requirements,  tradeoff  design 
features,  and  size  the  system  iteratively  until  the  best  configuration  forms  for  a  particular 
mission.  The  analysis  of  requirements  should  include  performance,  interfaces,  and  physical 
characteristics.  Design  tradeoffs  should  investigate  different  types  of  propulsion  systems, 
selection  criteria,  and  design  factors  for  the  specific  mission.  Through  use  of  sizing 
calculations  and  a  safety  factor,  types  and  quantities  of  the  various  propulsion  components 
can  be  determined,  including  propellants,  tank  configuration,  basic  subsystem  components, 
instrumentation,  power  conditioning,  and  pressurants.  All  decisions  must  be  made  within 
the  context  of  the  requirements  and  objectives. 
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The  propulsion  system  elements  are  affected  by  several  design  factors,  as  shown  in 


Figure  15-17. 


Velocity  Increment  Av 

-  Attitude  Control 
-Limit  Cycling 
—  Managing  Momentum 
-  Spacecraft  Weight 

Allowable  Offset  for 
Center  of  Mass 
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Life  Time 


Maintenance  or 
Max  Interval  for  Supply 


PROPULSION  SYSTEM 

*  Thruster 
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Equipment 

*  Power  Equipment 
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ADDITIONAL 
^Interaction  with  the 
rocket  exhaust  plume 
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Response  Time 
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Component  Selection 


Propeilant  Load 
Tank  Sizing 


Figure  15-17:  Propulsion  Design  Factors 


Source:  Sackheim  and  others,  1992:660-661 


15.5.2.4.1  Design  Basics 

(1)  Tank  Location-.  Must  reside  at  or  near  the  spacecraft’s  center  of  mass  to  avoid  shifting 
of  the  center  of  mass  due  to  propellant  usage. 

(2)  Engine  Location-. 

(a)  Translational  Control.  Engines  for  translational  control  are  aligned  to  thrust 
through  the  center  of  mass. 
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(b)  Attitude  Control.  Engines  for  attitude  control  thrust  tangentially,  and  are 
mounted  as  far  away  from  the  center  of  mass  as  possible  to  increase  the  lever  arm,  thus 
increasing  the  torque  per  unit  thrust. 

(3)  Number  of  Engines:  Attitude  control  thrusters  that  fire  in  the  direction  of  flight  (along 
or  opposite  the  direction  of  the  velocity  vector)  are  generally  used  in  pairs  to  produce  a 
pure  torque  without  net  linear  force.  Three-axis  control  requires  a  minimum  of  six 
attitude  control  thrusters;  many  designs  use  eight  to  twelve  plus  backup  units  for 
reliability. 


15.5.2.4.2  Propellant  Mass 

For  a  typical  design,  the  propellant  load  is  sized  based  on  information  provided 
from  the  propellant  budget  table.  For  initial  sizing,  the  factors  to  consider  are  velocity 
correction  and  control,  and  attitude  control.  Propellant  load,  mp,  can  be  estimated  from 
the  total  impulse  requirements  (Sackheim  and  others,  1992:641); 


(Eqn  15-11) 

where  mf=  nio  -  mp :  the  final  vehicle  mass 
nio  :  initial  vehicle  mass 
mp :  mass  of  propellant  consumed 
R  :  mass  ratio  (  mio/  mf) 

Isp  :  specific  impulse 
g  :  gravitational  constant. 


m^  =  m^ 


m. 


Knowing  the  propellant  mass,  one  can  determine  the  propellant  volume,  Vp,  by 
dividing  by  propellant  density,  dp  (i.e.,  Vp  =  mp  /  dp). 


203 


15.5.2.4.3  Propellant  and  Pressurant  Volume  for  Tank  Sizing 

The  tank  may  be  sized  after  determining  the  propellant  load.  For  bi-propellant 
systems,  the  oxidizer  and  fuel  requirements  are  determined  from 

O  /  F  =  mox  /  mfuei  (Eqn  15-12) 

where  O  /  F  is  the  oxidizer  to  fuel  mixture  ratio  needed  to  deliver  the  required  specific 

impulse,  niox  is  the  oxidizer  mass,  and  mfUei  is  the  mass  of  the  fuel.  Tank  volumes  are 

calculated  from: 

•  Propellant  volumes  loaded  into  each  tank 

•  Reasonable  allowance  for  ullage  (gas  volume  in  the  propellant  tank,  approximately 
5%)  (Sackheim  and  others,  1992:659) 

•  Design  margin. 

•  Propellant  remaining  in  each  tank  because  of  trapped  liquids  or  uncertainties  in  loading 
and  performance. 

The  mixture  ratio  is  a  critical  parameter  in  propulsion  system  sizing;  therefore  its 
selection  is  the  first  step  in  determining  the  quantity  of  propellant  needed  to  satisfy  total 
impulse  requirements.  There  are  different  O  /  F  ratios  for  different  bi-propellant  couples. 
A  good  rule  of  thumb  is  to  use  equal  size  tanks,  since  this  simphfies  tank  manufacturing, 
subsystem  configuration  layout,  and  integration  into  the  spacecraft. 

For  a  mono-propellant  system,  the  above  discussion  is  valid,  except  that  there  is  no 
oxidizer. 

Pressurant  gas  requirements  depend  on  the  type  of  pressurization  system 
employed:  either  regulated,  blow-down  or  a  combination  of  the  two  (Figure  15-16:  Gas 
Pressure  Systems) 
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•  Regulated:  About  5-10%  ullage  is  provided  in  the  propellant  tanks.  The  tank  volume 
will  be  almost  the  same  as  the  propellant  volume,  since  the  pressurant  is  stored  in  the 
different  tank. 

•  Blow-down:  The  total  propellant  tank  volume  for  the  blow-down  system  is  the  sum  of 
the  propellant  volume,  Vp ,  and  initial  gas  volume,  Vgi,  in  the  tank.  The  blow-down 
ratio  is  (Sackheim  and  others,  1992:659): 


R  =  Vgf/Vgi  =  [  Vgi+Vp]/Vgi  (Eqn  15-13) 

where  Vgf  is  the  final  gas  volume,  neglecting  the  propellant  volume  remaining  at  the  end  of 
the  life  as  well  as  density  changes  with  temperature. 

One  can  allow  for  a  liquid  propellant  load  design  margin  of  about  25%,  and  a 
reasonable  residual  propellant  of  5%  for  early  conceptual  design. 

For  most  systems,  one  can  determine  the  pressurant  mass  from  the  perfect  gas  law, 
but  only  when  the  propellant  is  withdrawn  isothermally  (in  blow-down  systems  at  low  duty 
cycles).  Otherwise,  calculating  the  requirements  for  pressurant  mass  for  regulated  systems 
can  become  thermodynamically  complicated.  By  using  conservation  of  energy,  the 
pressurant  mass  can  be  determined  (Sackheim  and  others,  1992:660): 


= 


PV 

p  p 


RT 


-(pjp) 


(Eqn  15-14) 


where 

mgi :  initial  pressurant  mass 

Pp&  Vp :  instantaneous  gas  pressure  and  volume  in  the  propellant  tank 
Pg  (300-600  psia)&Pi(3 000-6000  psia):  instantaneous  gas  pressure  and  initial  gas 
pressure  in  the  pressurant  tank 
Ti :  initial  gas  temperature  (275-300  K) 

k  :  specific  heat  ratio  for  pressurant  gas  (1.40  nitrogen,  1.67  helium  etc.) 
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R  :  pressurant  gas  constant  (296.8  J/(Kg,K)  for  nitrogen,  2077.3  J/(Kg.K)  for 
helium  etc.) 

Note:  This  equation  does  not  apply  to  very  high  storage  pressures,  for  which  the 
compressibility  factor  becomes  important.  In  this  case,  the  volume  of  the  pressurant  can 
be  found  by  its  density. 

One  may  estimate  the  propellant  and  pressurant  gas  tank  weights  from  (Sackheim 
and  others,  1992:660): 

(Eqn  15-15) 

(Eqn  15-16) 

where  o  :  allowable  stress 

p  :  maximum  expected  operation  pressure 
r :  tank  radius 
t :  tank  thickness 

For  a  typical  spacecraft  propulsion  system,  the  tank  weight  will  be  about  5  to  15% 
of  the  propellant  weight,  depending  on  the  basic  design,  safety  factors,  and  construction 
materials.  Also,  one  must  add  20  to  30  %  of  the  overall  tank  weight  for  mounting  and 
propellant  management  devices  (Sackheim  and  others,  1992:660). 

Liquid  propulsion  systems  are  typically  85-93%  propellant  by  mass,  with  the 
remainder  consisting  of  pressurant,  thrusters,  tanks,  fluid  components,  lines,  fittings  and 
instrumentation  (Sackheim  and  others,  1992:660).  This  fuel  mass  fraction,  however,  can 
be  considerably  lower  in  small  systems,  such  as  Modsat.  Higher  fuel  mass  fractions  are 


pr 

(T  =  ^  (cylindrical) 
and 


vv 

cr  =  ^  (spherical) 
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usually  associated  with  large  propellant  loads  and  the  use  of  composite,  over-wrapped  hi- 
tech  tanks. 

15.5.2.5  Interfaces  Among  Subsystems  and  Other  Considerations 

The  interfaces  among  the  subsystems  are  shown  in  Figure  15-18.  The  following 
factors  must  be  considered; 

•  Thruster  exhaust  plume 

(a)  Plume  heating  of  surfaces  next  to  the  thruster. 

(b)  Forces  and  moments  that  the  plume  places  on  the  spacecraft.  For  example,  solar 
panel-related  drag  may  occur.  To  avoid  this,  the  thrusters  must  be  mounted  away 
from  the  solar  panels. 

(c)  Contamination  by  plume,  which  is  dependent  on  propellant  type,  may  affect  the 
sensitive  surfaces  (such  as  optics,  solar  cells,  thermal  control  surfaces,  I/R  sensors, 
etc.)  of  the  satellite.  Contamination  is  a  serious  coneem  if  the  plume  reduces  the 
solar  cell  efficiency  and  overall  available  electric  power. 

•  Maneuver  accuracy. 

•  The  propulsion  subsystem  does  not  use  much  electrical  power,  unless  it  employs 
thrusters  with  heated  catalyst  beds,  known  as  heated  thrusters.  Also,  propulsion  lines 
and  tanks  must  be  protected  from  freezing,  usually  by  thermostatically  controlled 
guard  heaters.  Power  for  these  heaters  is  included  in  the  thermal  subsystem. 
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Power  supply  for; 

•  Solenoids,  instruments,  and  sensors 

•  Telemetry  and  radio  communication 


•  Command  actuation  in  pitch,  yaw  and  roll 

•  Feedback  of  TVC  angle  position 

•  Slew  rate 

•  Duty  cycle 


•  Command  signal  for  start/stop/throttle,  etc. 

•  Feedback  signals  to  monitor  the  status  of  the  propulsion  system, 
e.g.  valve  positions,  thrust  level,  remaining  propellant,  pump 
pressures,  temperatures 


Figure  15-18:  Propulsion  Block  Diagram 


15.5.2.6  Propulsion  Options  For  Standard  Satellite  Bus  Alternatives 

Propulsion  subsystem  options  for  Modsat  were  modeled  and  chosen  with  the  aid 
of  the  Modsat  computer  model.  The  primary  alterables  for  the  propulsion  subsystem  are 
shown  in  Table  15-18, 


Table  15-18:  Propulsion  Alterables 


Alterable  Elements 

Possible  Options 

Propulsion  Type 

Liquid  mono-propellant 

Liquid  bi-propellant 

Pressure  System 

Blow-down 

Regulated 

Propellant  type 

Many 

Shape  of  Tanks 

Spherical 

Cylindrical 
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The  design  and  placement  of  the  Modsat  propulsion  subsystem  is  constrained 
primarily  by  the  volume  and  weight  limitations  of  the  Pegasus  Launch  Vehicle.  Therefore, 
volume  and  weight  considerations  are  major  criteria  for  the  selection  of  propulsion 
alterables. 

15.5.2.6.1  Propulsion  Subsystem  Location 

It  was  decided  that  the  entire  propulsion  subsystem  should  reside  on  the  bottom 
level  of  the  satellite  bus.  The  generic,  modular  nature  of  the  bus  precludes  any  other 
location  for  this  subsystem.  This  major  design  decision  was  made  after  discussing  the 
following  considerations; 

•  The  propellant  tanks  of  the  propulsion  system  are  some  of  the  heaviest  components  of 
the  satellite  bus.  Launch  vehicle  considerations  deem  that  the  center  of  gravity  of  the 
spacecraft  be  as  low  as  possible  on  the  LV/spacecraft  z-axis. 

•  Since  the  specific  mission  modules  that  will  be  flown  on  Modsat  are  unknown,  it  is 
wise  to  keep  any  thrusters  well  below  the  bus-to-mission  module  interface. 

•  For  some  of  the  candidate  system  solutions,  there  is  free  space  for  the  insertion  of 
additional  components.  Therefore,  the  final  configuration  of  the  bus  is  unknown. 

This  makes  it  difficult  to  place  valves  and  thrusters  anywhere  above  the  bottom  of  the 
bus.  Even  in  the  candidates  systems  that  don’t  have  the  free  space,  it  is  quite  difficult 
to  locate  propulsion  equipment  amid  the  other  subsystems. 

•  The  effects  of  thruster  exhaust  plume  and  other  possible  contamination  from  the 
propulsion  system  are  reduced  by  locating  it  on  a  designated  bottom  plate. 
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•  The  propulsion  subsystem  does  not  fit  in  well  with  the  modular  nature  of  the  bus,  with 
its  removable  components  and  structural  assemblies  (see  section  15.5.3).  Propulsion 
equipment  includes  relatively  large  structures  (tanks)  and  complicated  fuel  delivery 
systems  that  do  not  lend  themselves  to  modularity,  or  removal  and  replacement.  It 
would  be  extremely  difficult  to  locate  any  of  these  components  and  systems  anywhere 
other  than  on  a  fixed  plate  at  the  bottom  of  the  bus. 

•  The  weight  of  pipes,  vanes,  valves,  and  the  other  propulsion  plumbing  equipment  is 
reduced  by  consolidating  the  whole  subsystem  in  one  location. 

Despite  these  considerations,  the  Modsat  model  provides  the  engineer  with 
maximum  flexibility  in  the  placement  of  subsystems  and  components.  Future  efforts  could 
examine  other  placement  schemes  for  the  propulsion  subsystem. 


15.5.2.6.2  Propellant  Tank  Geometry 

The  bottom  level  of  Modsat  is  dedicated  for  the  propulsion  subsystem,  with  the 
exception  of  one  SGLS  antenna.  This  level  is  an  octagon  of  approximately  86  cm 
diameter;  a  5  cm  square  structural  spine  runs  through  the  center  (see  section  15.5.3;  see 
also  Volume  III).  Note  that  this  spine  precludes  a  centered  one-tank  configuration.  The 
location  of  the  satellite  center  of  mass  is  critical,  both  in  the  launch  phase  or  during  on- 
orbit  operations.  The  tank(s)  should  be  balanced  with  respect  to  the  central  axis  of  the 
spacecraft,  and  must  be  placed  as  near  as  possible  to  this  axis. 

For  simplicity,  and  in  order  to  make  efficient  use  of  the  space  in  the  bottom  level,  it 
was  decided  that  the  tanks  should  have  a  common  shape.  Although  the  most  common 
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tank  shape  is  a  sphere,  cylindrical  tanks  are  also  acceptable  and  reasonable.  The  tanks 
should  lie  on  the  bottom,  in  order  to  minimize  the  total  height  occupied  by  the  tanks  (see 
Figure  15-19). 


Height  =  Diameter  of  sphere  Height  =  Diameter  of  cylinder 


Figure  15-19:  The  Difference  in  Height  Between  Spherical  and  Cylindrical  Tanks 

Initially,  identical  dimensions  were  chosen  for  the  cylindrical  tanks,  in  order  to 
distribute  the  mass  symmetrically.  However,  the  position  of  the  identical  cylindrical  tanks 
on  the  plate  is  not  optimum,  as  there  is  a  great  deal  of  leftover  space.  This  space  could  be 
used  if  the  lengths  of  the  cylinders  were  allowed  to  be  different  from  each  other;  thus  more 
propellant  could  be  stored  (see  Figure  15-20 ).  In  the  identical  configuration,  this  loss  of 
additional  storage  space  in  the  length  of  the  cylinders  must  be  compensated  by  increasing 
the  radius  of  the  cylinders,  which  in  turn  raises  the  height  of  the  spacecraft. 

The  lengths  of  the  cylindrical  tanks  are  limited  by  the  size  of  the  octagon  mounting 
plate,  as  well  as  by  the  central  spine  that  runs  through  the  structure  (see  section  15.5.3). 

Through  basic  analysis  of  the  geometry  of  the  mounting  plate,  it  was  determined 
that  use  of  the  bottom  level  is  maximized  by  the  combination  of  one  pair  of  42  cm-long 
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cylinders  and  one  pair  of  33  cm-long  cylinders  (see  Figure  15-20).  For  a  given  radius,  the 
equivalent  volume  of  four  identically-sized  spherical  tanks  requires  around  7  cm  of 
additional  height  (calculations  were  done  for  a  mono-propellant,  blow-down  system 
supplying  450  m/s  of  AV).  This  difference  in  height  is  significant  for  a  small  spacecraft. 
Thus,  cylindrical  tanks  of  the  size  described  above  were  chosen  for  Modsat. 


4  identical  cylindrical  tank  distribution  Optimum  tank  sizes  and  their  distribution 

Figure  15-20:  Location  and  Size  of  Cylindrical  Tanks 


15.5.2.6.3  Bi-propellant  versus  Mono-propellant 

Although  bi-propellants  have  greater  specific  impulses,  Isp,  than  mono-propellants. 
Table  15-19  shows  that  the  difference  in  required  volume  between  bi-propellants  and 
mono-propellants  is  small.  This  comparison  was  done  by  assuming  a  configuration  of  four 
cylindrical  tanks,  blow-down  regulation,  and  enough  propellant  to  deliver  450  m/s  of  AV. 
The  bi-propellant  system  used  two  oxidizer  and  two  fuel  tanks.  The  fuels  used  in  the 
comparison  were  those  that  deliver  the  highest  specific  impulse  of  the  candidate  blends 
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listed  in  Table  15-16  and  Table  15-17.  Thus,  the  mono-propellant  system  used  the  24% 
HN  -  76%N2H4  blend  (Isp=263  m/s),  while  the  bi-propellant  system  used  the  Fluorine  - 
Hydrazine  combination  (Isp=363  m/s). 


Table  15-19:  Mono-propellant  and  Bi-propellant  Results 


Propellant  Type 

42  cm  Cylinder 
Radius 

33  cm  Cylinder 
Radius 

Mono-propellant 

9.91 

9.96 

Bi-propellant  Fuel 

8.00 

8.92 

Bi-propellant  Oxidizer 

8.04 

8.97 

Although  there  was  not  a  big  difference  in  the  heights  of  the  cylinders,  the  mono¬ 
propellant  configuration  was  chosen  as  the  Modsat  standard  because  of  its  simplicity, 
cost,  and  reliability  advantages  (Sackheim  and  others,  1992:645). 


15.5.2.6.4  Blow-down  versus  Regulated 

Modsat  does  not  require  the  capability  for  high-level  long-duration  thrust.  In  fact, 
it  is  clear  that  a  low-thrust,  small  propulsion  system  is  adequate.  Thus,  even  though  the 
allowable  thrust  of  a  blow-down  propellant  feed  system  decreases  with  bum  time,  it  is 
suitable  for  Modsat.  Moreover,  since  blow-down  systems  do  not  need  regulators,  and 
sometimes  even  filters,  they  are  simple  and  reliable  (Sutton,  1992:326).  Therefore,  the 
blow-down  configuration  is  the  best  choice  for  the  Modsat  propellant  feed  function. 
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15.5.2.6.5  Pressure  Range  for  the  System 

The  mass  and  volume  of  the  pressurant  are  dictated  by  the  minimum  pressure 
allowed  for  the  propulsion  subsystem.  For  a  nominal  propulsion  system,  end-of-life 
pressure  is  about  680  kPa  (100  psia),  and  beginning-of-life  pressure  is  about  2.07-2.76 
MPa  (300-400  psia)  (Sackheim  and  others,  1992:654).  For  the  propellant  tank  sizing 
calculations,  initial  pressure  and  final  pressure  were  chosen  to  be  680  kPa  -  2.76  MPa 
(100-400  psia),  respectively. 

15.5.2.6.6  Propulsion  Structures  and  Materials 

The  propellant  database  used  for  this  study  covers  only  major  hydrazine  blends  and 
combinations.  Thus,  the  structures  and  materials  must  be  compatible  with  hydrazine  fuels. 
Information  on  the  general  subject  of  compatibility  of  materials  with  hydrazine  fuels  is 
extensive,  and  a  complete  discussion  of  the  subject  is  beyond  the  scope  of  this  study. 
However,  a  few  guidelines  with  regard  to  compatibility  can  be  suggested. 

Hydrazine  is  compatible  with  a  wide  variety  of  the  materials  that  could  be  used  in 
the  construction  of  the  subsystem.  However,  care  must  be  exercised  in  selecting  suitable 
materials,  due  to  the  reactive  properties  of  hydrazine  and  the  necessity  of  minimizing 
propellant  spills  and  leaks.  Since  hydrazine  reacts  with  air,  as  well  as  some  metal  oxides 
and  oxidizing  agents,  and  absorbs  water  readily,  storage  and  transport  systems  must  be 
free  from  air,  moisture,  rust  and  contamination.  Additionally,  the  lubricants,  solvents  and 
gaskets  utilized  in  these  systems  must  be  chemically  inert  to  hydrazine. 
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In  a  hydrazine  system,  those  metallic  components  which  may  have  long-term 
contact  with  the  propellant  include  the  propellant  tank(s),  propellant  lines,  and  valves.  For 
a  system  utilizing  neat  hydrazine  (by  far  the  most  common),  the  list  of  compatible  metals 


includes  certain  titaniums,  stainless  (corrosion  resistant)  steels  and  aluminums.  If  the 
selected  propellant  is  a  hydrazine  and  water  blend,  the  aluminums  are  ruled  out;  if  a  blend 
utilizing  hydrazine  nitrate  is  used,  the  stainless  steels  are  eliminated.  This  information  is 
summarized  in  Table  15-20. 


Table  15-20:  Compatible  Metals  for  Hydrazine  Systems 


Material 

Neat 

Hydrazine 

Binary 

N2H4/ 

H2O 

Blends 

Binary 

N2H4/N2H5NO3 

Blends 

Ternary 
H2H4/H2O/N2 
H5NO3  Blends 

Titanium  (6A1-4V,  pure) 

Acceptable 

Acceptabl 

Q 

Acceptable 

Acceptable 

Stainless  Steel 

Acceptable 

Acceptabl 

Not 

Not 

(302,  303,  304L,  316,  17- 
7,  430,  446,  355,  350) 

e 

Acceptable 

Acceptable 

Aluminum 
(6061-T6,  2014-T6) 

Acceptable 

Acceptabl 

e 

Marginal 

Not 

Acceptable 

Source:  Hydrazine  Handbook  2-20. 


The  propellant  which  has  the  highest  specific  impulse  (Isp)  is  the  24%HN  and  76% 
N2H4  blend.  Only  titanium  is  acceptable  for  that  propellant.  Therefore,  titanium  was 
chosen  as  the  structural  material,  for  its  compatibility  with  all  of  the  hydrazine  blends. 


15.5.2.6.7  Thrusters 

The  short  mission  life,  weight  and  volume  constraints  point  to  the  use  of  a  single 
string  thruster  combination.  Therefore,  Modsat  uses  the  minimum  number  of  thrusters 
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necessary  to  perform  the  intended  propulsion  functions.  It  was  determined  that  six 
thrusters  would  be  adequate.  The  two  axial  thrusters  are  placed  vertically,  perpendicular 
to  the  bottom  plate.  The  roll  thrusters  are  located  on  the  sides,  tangential  to  the  edge  of 
the  octagon.  The  pitch  thrusters  are  located  at  the  sides,  and  are  tilted  at  an  angle  as 
shown  in  Figure  15-21. 


Figure  15-21:  Location  of  Pitch  Thrusters 


The  thrusters  are  located  inside  the  bus,  at  the  bottom  level,  and  are  located  as  far 
as  possible  from  the  center  of  gravity,  in  order  to  produce  a  large  moment  arm.  The  size  of 
the  thrusters  is  normally  dictated  by  mission  requirements.  However,  since  Modsat  must 
accommodate  a  variety  of  mission  profiles,  some  of  them  requiring  large  amounts  of 
thrust,  a  highly  capable  set  of  22.4  N  (5  Ibf)  thrusters  was  chosen.  It  should  be  noted  that 
the  Modsat  computer  model  can  easily  be  used  to  model  the  use  of  different  thrusters, 
should  the  need  arise. 
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15.5.2.7  Propulsion  Alternatives 


After  making  the  design  decisions  discussed  above,  the  remaining  propulsion 
alterable  is  the  amount  of  propellant,  which  dictates  the  size  of  the  cylindrical  tanks.  Thus, 
all  of  the  major  system  alternatives  for  this  study  were  designed  with  a  mono-propellant 
(24%HIS1  and  76%  N2H4  blend),  blow-down  pressure  fed  system  with  cylindrical  tanks. 

Although  the  mission  requirements  are  uncertain,  the  idea  behind  the  propellant 
alterable  was  to  provide  different  amounts  of  AV  capability.  This  capability  must  be 
divided  among  the  spacecraft  AV  budget,  which  accounts  for  tactical  maneuver  capability, 
mission  life  time,  retirement,  and  orbital  accuracy.  For  a  given  amount  of  propellant,  this 
budget  must  be  managed  by  the  user  of  Modsat. 

The  baseline  orbit  for  Modsat  was  chosen  to  be  350  km.  The  amount  of  AV 
required  to  maintain  this  orbital  altitude  is  62.2  m/s  per  year.  At  this  altitude,  the  amount 
of  A  V  required  to  make  a  one  degree  plane  change  is  134.3  m/s  (Larson  and  Wertz,  1992: 
back  cover).  It  was  assumed  that  momentum  management  will  require  35-50  m/s  of  AV 
per  year.  The  chosen  propulsion  alternatives  for  this  study  are  shown  in  Table  15-21. 


Table  15-21:  Propulsion  System  Alternatives 


Alternative 

Altitude 

Keeping 

(m/s) 

Momentum 

Dumping 

(m/s) 

Inclination 

Change 

(m/s) 

Total  A  V 
(m/s) 

1 

62.2 

37.80 

-  /  0 

100 

2 

62.2 

36.35 

201.45  /  1.5 

300 

3 

62.2 

52.05 

335.75  /2.5 

450 

217 


Although  the  placement  of  thrusters  was  fixed,  for  each  alternative  the  propellant 
tanks  are  located  as  near  as  possible  to  the  center,  in  order  to  minimize  the  effect  of 
diminishing  propellant. 


Figure  15-22:  The  Propulsion  System 

15.5.3  Structures  and  Mechanisms 

15.5.3.1  Introduction 

This  section  of  the  report  presents  a  systems  engineering  approach  to  designing  the 
structure  of  Modsat.  This  structural  trade  study  details  the  steps  and  assumptions  made  to 
reduce  the  many  possible  structural  design  architectures.  Only  those  viable  alternatives 
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satisfying  the  specific  satellite  missions  called  out  for  Modsat  were  considered  for 
modeling.  The  best  structural  designs  fi'om  the  several  possible  Modsat  designs  are 
presented. 

To  conduct  this  structural  study,  a  clear  understanding  of  the  problem  was  necessary. 
The  problem  is  to  design  a  small  and  inexpensive,  light-weight  structure  capable  of 
supporting  tactical  operations.  To  solve  this  problem,  objectives  must  be  defined.  Among 
the  many  objectives  and  values  for  Modsat,  low-cost  and  the  desire  to  “launch-on-need” 
have  the  greatest  influence  on  the  structural  design.  Fulfilling  these  attributes  is  key  if 
Modsat  is  to  support  various  tactical  operations  anywhere  in  the  world.  Therefore,  the 
satisfaction  of  these  constraints  was  a  major  design  goal  for  this  structures  design  study. 

15.5.3.2  Determining  Feasible  Structural  Designs 

In  support  of  a  low-cost  design,  graphite  and  composite  materials  were  not 
considered.  Although  graphite-epoxy  composites  provide  “...extremely  high  stiffhess-to- 
weight  ratios...” ,  they  are  costly  and  “...often  require  a  long,  expensive  development 
program  to  establish  manufacturing  processes”  (Doukas  and  others,  1992:435-441). 
Because  the  use  of  composites  increase  the  complexity  of  the  structure  and  drives  up 
construction  costs,  the  use  of  other  metallic  alloys,  such  as  aluminum,  is  more  desirable. 
According  to  Doukas,  et  al,  “Aluminum  is  relatively  light-weight,  strong,  readily  available, 
easy  to  machine,  and  low  in  raw  material  cost”  (Doukas  and  others,  1992:435-441). 
Therefore,  only  aluminum  alloys  were  considered  for  the  main  structure  of  Modsat.  In 
fact,  until  recently,  the  primary  structure  of  MightySat,  a  common  bus  platform  for  testing 


new  technologies  for  Phillips  Laboratory,  was  being  built  exclusively  with  aluminum 
(MightySat  TRD,  1996:79). 

‘‘Launch-on-need”  implies  the  ability  to  launch  within  a  few  days,  as  opposed  to 
several  months,  as  with  current  launch  schedules.  Since  the  satellite  bus  must  be  able  to 
support  multiple  mission  modules,  modular  design  schemes  seem  to  be  the  most  viable 
answer  to  a  quick  response  launch.  To  incorporate  modularity  into  the  Modsat  design,  the 
team  developed  modular  mounting  plates.  Such  architectures  allow  for  quick  assembly, 
test,  and  check  out.  Of  course,  this  will  necessitate  the  development  of  flexible  operating 
system  software  to  compensate  for  hardware  changes.  To  further  satisfy  the  “launch-on- 
need”  requirement,  the  satellite  bus  design  must  allow  for  quick  mission  module  and 
launch  vehicle  integration.  In  addition,  the  ease  of  removing,  replacing,  and  adding 
internal  subassembly  components  is  essential  to  last  minute  launch  preparations. 

To  begin  studying  the  structural  design,  the  team  first  looked  at  the  volume 
considerations  governed  by  the  payload  shroud  of  the  launch  vehicle  (see  Figure  15-23). 
As  shown,  the  team  divided  the  total  satellite  into  two  main  parts:  mission  module  and 
satellite  bus.  The  mission  module  is  comprised  of  the  mission  payload  and  its  supporting 
subcomponents.  The  satellite  bus,  containing  the  CPU,  power,  communications,  etc., 
maintains  the  satellite  and  supports  the  mission  module.  For  the  purpose  of  the  Modsat 
study,  the  team  focused  primarily  on  the  satellite  bus  design,  while  striving  to  meet 
potential  mission  module  requirements. 
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Figure  15-23:  Payload  Configuration 


Since  the  Pegasus  XL  is  Modsat’s  primary  launch  vehicle,  the  team  first  concentrated 
its  efforts  on  ensuring  that  the  satellite  bus  and  mission  module  combination  would  fit 
within  the  Pegasus  payload  bay,  as  depicted  earlier  in  this  report. 

The  next  consideration  in  selecting  a  satellite  structure  was  to  select  a  geometric  shape 
that  best  utilizes  the  payload  bay’s  volume  and  maximizes  solar  access  (see  Figure  15-24). 


Figure  15-24;  Structure  Shapes 


To  do  this,  the  team  first  maximized  each  geometric  shape  for  volume  within  the 
cylindrical  payload  bay  (34.27  inch  height  x  39.5  inch  diameter)  for  the  Pegasus  XL  23” 
payload  interface  configuration.  Once  the  shape’s  maximum  dimensions  were  obtained. 


solar  access  was  calculated,  assuming  the  entire  surface  area  of  the  geometric  shape.  The 
results  shown  below  in  Table  15-22  are  taken  from  the  calculations  in  Appendix  B, 
Structures  and  Mechanisms. 


Table  15-22:  Geometric  Shape  Volume  and  Solar  Access 


Payload  Bay  (Cylinder) 
(34.37  inch  diameter  x 
39.5  inch  height) 

Volume  (cm^) 

Max:  688,176 

Solar  Access  (cm^) 
Max:  43,248 

Hexagon 

569,117 

39,276 

Sphere 

345,336 

23,804 

Cube 

438,106 

34,768 

Cylinder 

688,176 

43,248 

Although  this  table  clearly  shows  the  sphere  and  cube  to  be  a  poor  choices  for 
maximizing  volume  or  solar  access,  the  team  discovered  an  interesting  relationship.  While 
performing  the  volume  and  surface  area  calculations  for  the  various  geometric  shapes,  the 
team  found  that  except  for  the  sphere,  the  geometric  shapes  are  of  similar  construction. 
The  remaining  geometric  shapes  differing  only  in  the  number  of  sides,  as  depicted  in 
Figure  15-25.  Again  referring  to  Figure  15-25  and  Table  15-22,  one  can  see  how 
increasing  the  number  of  sides  utilizes  more  volume  and  provides  more  solar  access; 
however,  there  is  a  diminishing  return  to  increasing  the  number  of  sides. 


Number  of  sides 

Figure  15-25:  Geometric  Shapes  with  Similar  Properties 
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In  fact,  the  volume  and  surface  area  calculations  for  the  rectangle  and  hexagon  were 
done  with  the  same  general  equations.  Although  it  appears  that  a  cylindrical  bus  is  the 
best  geometric  shape,  the  increased  weight,  limited  access  to  subcomponents,  and 
restricted  solar  wing  placement  in  the  stowed  configuration  make  it  a  less  desirable  choice. 
Incidentally,  Leritz  and  Palmer,  in  considering  a  geometric  shape  for  their  satellite  design 
example,  selected  the  cylinder  and  hexagon  because  they  “distribute  loads  more 
uniformly”  (Leritz  and  Palmer,  1995:490).  From  volume,  surface  area,  and  loading 
considerations,  it  seems  likely  that  the  best  Modsat  structural  design  is  a  “poly sat,"  an  n- 
sided  polygon.  By  varying  the  number  sides,  the  best  Modsat  design  can  be  found. 
Therefore,  the  “polysat”  design  became  the  main  focus  of  structural  modeling. 

Next,  the  team  investigated  what  geometric  shapes  minimize  materials  and  maximize 
internal  subcomponent  outside  accessibility.  Figure  15-26  below  illustrates  possible 
satellite  bus  designs. 


Figure  15-26:  Exterior  Structural  Makeup  for  Geometric  Shapes 


In  building  a  generic  satellite  bus,  it  is  important  to  minimize  weight  while  maximizing 
payload  weight  and  meeting  launch  and  on-orbit  loading  requirements.  For  example,  if 
one  considers  the  fact  that  about  a  fifth  of  the  weight  in  communication  satellites  is 
framework  (Larson  and  Wertz,  1992:  806),  designing  a  satellite  bus  to  meet  total  weight 
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and  loading  requirements  is  difficult.  The  challenge  is  in  satisfying  these  conflicting 
requirements. 

Another  consideration  in  the  design  of  a  satellite  bus  is  the  accessibility  of  internal 
subcomponents.  This  is  concern  with  how  easy  it  is  to  reach  inside  the  satellite  from  the 
outside.  This  could  be  important  for  last  minute  launch  preparations.  Although  it  is 
possible  to  space  out  structural  members  farther  apart  for  cylindrical  and  spherical  bus 
designs,  the  number  of  members  still  exceeds  that  of  the  “polysat”  designs.  Also,  internal 
component  accessibility  from  the  outside  is  more  impeded  than  with  “polysat”  designs. 

The  final  external  structure  consideration  is  the  ease  of  mating  the  structure  to  the 
launch  vehicle  the  mission  module.  Except  for  sphere  all  the  designs  have  flat  bottom  and 
top  surfaces,  allowing  for  easier  integration  with  the  launch  vehicle  and  mission  module. 

The  results  for  material  usage,  component  accessibility,  and  payload/launch  vehicle 
interface  compatibility  are  shown  below  in  Table  15-23.  Actual  calculations  for 
minimizing  materials  can  be  found  in  Appendix  B.  The  component  accessibility  and 
payload  compatibility  ratings  are  based  on  1-5  scale  with  5  being  the  best.  The  following 
ratings  are  based  on  the  team’s  assessment. 

Table  15-23:  Minimizing  Materials  and  Maximizing  Access  for  Geometric  Shapes 


Structure 

Type 

Minimizes 
Materials  (cm) 

Component 

Accessibility 

Payload/Launch  Vehicle 
Interface  Compatibility 

Hexagon 

1,124 

4 

5 

Sphere 

2,735 

1 

1 

Cube 

915 

5 

5 

Cylinder 

1,501 

2 

5 
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The  next  consideration  of  the  team  was  to  choose  a  satellite  bus  structure  that  best 
suits  the  goals  for  “low-cost”  and  “launch-on-need.”  Figure  15-27  below  depicts  just  a 
few  possible  structural  designs.  The  team  evaluated  each  of  these  designs  on  how  well 
they  met  the  following  objectives  while  supporting  the  “polysat”  design  architecture. 

Modularity  and  Subcomponent  Accessibility:  How  modular  is  the  design  and 
how  easy  is  it  to  remove  and  replace  subassembly  components? 

Materials  Usage:  Does  this  design  minimize  the  use  of  materials  in  its 
construction? 

Structural  riaiditv:  What  is  the  inherent  strength  and  stiffness  of  the  structure? 
Manufacturina:  What  is  the  level  of  difficulty  to  construct  the  structure? 

Based  on  these  criteria  the  following  designs  in  Figure  15-27  were  evaluated  using  a 
pair-wise  comparison  technique  (see  Appendix  B). 


Figure  15-27:  Satellite  Bus  Types 


Caue:  The  structure  is  made  up  of  a  variable  number  of  sides  with  each  comer 
constmcted  with  a  load  bearing  beam.  The  beams  used  in  the  stmcture’s 
constmction  are  normally  welded  or  bolted  together  or  both.  This  design  is  the 
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closet  to  the  “polysat”  design  discussed  earlier.  Although  this  design  received  high 
marks  for  modularity  and  manufacturing,  it  scored  below  average  in  material  usage 
and  structural  stiffiiess. 

Truss;  This  structure  mimics  those  used  for  future  space  constructions.  The 
construction  resembles  that  of  tinker  toys  where  beams  are  joined  through  the  use 
of  coimecting  hubs.  This  design  scores  above  average  in  all  categories  except  for 
modularity. 

Blocks;  This  design  incorporates  the  bolting  together  of  subassembly 
components.  The  block  design  is  the  strongest  of  all  design,  but  at  the  expense  of 
added  weight  and  machining. 

Shelf;  Most  satellite  designs  use  the  box  frame  with  shelves  to  layer  the  placement 
of  payload  and  subassembly  components.  Once  the  shelf  is  installed,  it  becomes 
fixed  with  the  structure.  It  becomes  increasingly  more  difficult  to  remove  as  more 
components  and  shelves  are  added.  This  type  of  design  received  average  scores 
for  material  usage  and  manufacturing,  and  below  average  scores  for  modularity 
and  structural  rigidity. 

Drawer;  This  structure,  a  modified  “Shelf’  design,  incorporates  a  pull-out  and 
plug-in  design.  Although  its  modularity  scored  improved,  the  drawers  add  extra 
weight  and  complexity  to  the  design. 

Through  pairwise  comparison  the  team  evaluated  the  five  structural  design  for  each 
objective  listed  above.  Table  15-24  below  shows  how  each  satellite  design  did  against  the 
for  each  objective.  For  individual  scoring  results  see  Appendix  B. 
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Table  15-24:  Assessing  Satellite  Bus  Types 


Modularity 

Materials 

Usage 

Structural 

Rigidity 

Manufacturing 

Total 

Cage 

13 

9 

5 

14 

41 

Truss 

4 

14 

10 

11 

38 

Blocks 

9 

3 

15 

3 

30 

Shelf 

5 

9 

3 

8 

25 

Drawer 

9 

5 

5 

4 

23 

15.5.3.3  Structural  Design  Assessment 

Up  to  this  point  in  this  study,  two  basic  structural  concepts  were  examined.  First, 
the  team  started  from  a  very  basic  level  and  investigated  which  geometric  shape  best 
maximizes  the  volume  while  keeping  material  usage  down.  Although  it  was  determined 
that  Modsat  should  have  a  “polysat”  structure,  the  best  polysat  configuration  can  only  be 
found  upon  modeling  the  complete  Modsat  bus  design.  Second,  the  team  reviewed  both 
current  and  revolutionary  designs  to  determine  the  best  functional  design.  Although  the 
“Cage”  and  the  “Truss”  scored  well,  the  ‘Truss”  will  require  additional  harnesses  and 
brackets  to  support  subcomponent  attachments.  Therefore,  the  team  decided  to  design 
Modsat  with  the  “Cage”  configuration,  which  best  supports  the  “polysat”  design. 


15.5.3.4  Polysat  Design 

Since  it  was  determined  that  the  best  shape  for  Modsat  is  a  “polysat”,  it  is  necessary 
to  find  the  optimal  number  of  sides  to  build  the  Modsat  bus  structure. 

Although  the  number  of  sides  is  a  design  variable  and  can  be  specified  in  the  model, 
this  number  should  be  minimized.  By  doing  so,  more  space  is  allowed  between  support 
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beams,  granting  greater  side  access  to  the  subcomponents.  However,  the  other 
consideration  is  the  solar  panels.  As  the  number  of  sides  increases,  so  does  the  number  of 
folds  in  the  solar  array  structure  (see  Section  15.5.3.5).  This  increases  the  complexity  of 
the  solar  panel  design  and  reduces  the  reliability  of  its  structure.  Therefore,  the  main 
driver  is  to  select  the  minimum  number  of  sides  to  obtain  the  solar  panel  area  necessary  to 
meet  power  requirements.  Through  extensive  modeling  the  octagon  was  chosen  as  the 
baseline  structure  because  it  makes  good  use  of  the  LV  fairing  volume  while  meeting 
power  requirements. 

15.5.3.5  Solar  Panels  Design  and  Assessment 

The  requirement  for  large  amounts  of  electrical  power  played  an  important  part  in  the 
design  of  the  Modsat  structure.  To  meet  the  power  supply  goal  of  up  to  500  watts, 
considerably  large  solar  panels  are  necessary.  Modeling  for  the  electrical  power 
subsystem  (EPS)  determined  that  up  to  seven  square  meters  of  solar  array  area  would  be 
required  (see  section  15.5.6.4.3).  Thus,  the  determination  of  the  solar  wing  placement  and 
deployment  mechanisms  proved  to  be  a  sizable  challenge. 

Since  the  structural  design  focused  on  maximizing  internal  volume,  the  team 
discounted  the  use  of  a  folded-wing  configuration  for  the  stowed  arrays,  due  to  its 
inefficient  use  of  space  within  the  launch  vehicle  fairing  shown  in  Figure  15-28. 
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Figure  15-28:  Folded  Solar  Array  Conflguration 

The  team  also  considered  a  deployment  scheme  similar  to  that  used  by  Milstar,  where 

the  arrays  spread  out  accordion-style  from  a  small  canister.  Although  this  approach  saves 
a  great  deal  of  space,  it  is  very  technologically  complex  and  costly.  Therefore,  the  team 
decided  to  wrap  the  solar  array  assemblies  around  the  bus  as  shown  below  in  Figure  15- 
29. 


Figure  15-29:  Top  View  of  the  Solar  Panel  Configuration  During  Launch 

This  approach  was  successfully  used  by  the  Clementine  program  (Clementine  Report).  In 
this  configuration,  the  solar  array  assemblies  must  be  constructed  and  hinged  so  as  to  fold 
around  the  polygon  perimeter  of  the  bus.  This  technique  makes  efficient  use  of  the  space 
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within  the  launch  vehicle  fairing  by  placing  the  solar  panels  along  the  perimeter  of  the 
launch  vehicle’s  payload  bay  as  shown  below  in  Figure  15-30.  Moreover,  since  the  most 
severe  launch  loads  are  in  the  axial  direction,  the  vertical  placement  of  the  arrays  has 
structural  advantages. 

Since  the  amount  of  power  generated  by  an  array  is  proportional  to  its  area,  it  is 
desirable  to  maximize  the  surface  area  of  the  solar  array  assemblies.  The  surface  area  is 
determined  by  the  circumference  of  the  perimeter  of  the  “polysat”  and  the  height  in  the 
stowed  configuration  shown  below. 


Figure  15-30:  Side  View  of  the  Solar  Panel  Conflguration  During  Launch 

Note  that  in  the  stowed  configuration,  where  the  arrays  are  folded  around  the  spacecraft 
structure,  the  height  of  the  arrays  corresponds  to  the  width  of  the  solar  panels  in  the 
deployed  configuration  shown  below. 
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Figure  15-31:  Deployed  Solar  Panels  During  On-orbit  Operations 


It  was  decided  that  in  order  to  simplify  the  design  and  construction  of  the  solar  array 
assemblies,  they  would  not  be  allowed  to  extend  in  height  beyond  the  curve  in  the  Pegasus 
fairing.  Any  protrusion  beyond  this  curve  would  require  the  use  of  special  hinges  and 
mechanisms,  which  would  drive  up  cost  and  decrease  the  structural  reliability  of  the 
assemblies.  Therefore,  the  maximum  height  of  the  stowed  solar  arrays  is  dictated  by  the 
distance  from  the  LV-to-spacecraft  interface  plane  to  the  curve  in  the  fairing. 

The  Pegasus  configuration  that  maximizes  this  distance  is  the  38”  ring/without  HAPS 
option.  Throughout  the  modeling  effort  it  became  clear  that  the  solar  array  surface  area 
provided  by  one  wrap  around  the  bus  would  not  be  sufficient  to  meet  the  power 
requirement.  Even  with  if  the  arrays  could  be  perfectly  folded  around  a  cylindrical 
structure  (“polysat”  with  infinite  number  of  sides),  the  provided  wrap  area  would  still  not 
be  nearly  enough  to  provide  the  required  power.  Although  the  number  of  wraps  was  left 
as  a  design  variable  for  optimization,  it  was  recognized  that  at  least  two  wraps  would  be 
necessary.  Due  to  deployment  difficulties  and  reliability  considerations  solar  wing  wraps 
beyond  two  was  not  considered. 


It  must  be  noted  that  the  solar  array  assemblies  will  have  a  certain  thickness.  Even 
though  the  solar  cells  are  quite  thin,  they  require  a  semi-rigid  support  structure  such  as  the 
honeycomb  panels  shown  below  in  Figure  15-32. 


Source:  Sarafin  and  others,  1995:528) 

Figure  15-32:  Honeycomb  Panel  Construction 

This  structure  must  include  hinges.  Moreover,  since  the  solar  array  assemblies  will  be 
wrapped  around  the  bus  during  the  stressful  environment  of  launch,  they  must  include 
pads,  bumpers,  and  other  protection  devices.  The  thickness  of  the  assemblies  can  be 
varied  in  the  model.  To  be  conservative  the  team  chose  four  centimeters  as  solar  wing 
thickness.  Thus,  each  wrap  of  the  assemblies  takes  eight  centimeters  from  the  allowable 
diameter  of  the  bus. 

As  discussed  earlier,  it  is  clear  the  wrap  around  design  provides  the  best  means  of 
maximizing  solar  wing  area  with  minimum  volume  impact  for  the  mission  module  and 
satellite  bus.  As  for  multiple  wraps,  beyond  two  is  a  major  design  challenge  and  should 
be  discouraged. 
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15.5.3.6  Structure  analysis 


In  the  evaluation  of  satellite  stmctures,  one  must  consider  the  loads  on  the  satellite 
during  preprocessing,  launch,  and  on-orbit  operations.  The  satellite  loading  environments 
also  include  storage  and  handling,  transportation  to  the  launch  pad,  and  on-orbit  thermal 
stresses.  Because  the  most  significant  loads  are  during  launch  and  ascent,  the  team  only 
investigated  axial  and  lateral  loads.  For  the  Pegasus  launch  vehicles  these  loads  can  be 
considerable  (Everett,  1996).  For  the  purpose  of  this  study,  the  team  used  13  g’s  axial 
loading  and  6.0  g’s  lateral  loading,  as  specified  in  Table  1  in  “Tactical  Support 
Satellite/Standard  Payload  Interface  (TSS/SPI)  Study”  (Kim  and  Law,  1994;  13).  To 
ensure  a  structural  integrity,  the  team  built  the  design  with  a  1.6  yield  design  factor  of 
safety  for  a  “no  structural  test”  specified  in  Table  1 1-48  of  SMAD  (Doukas  and  others, 
1992:439). 

To  show  the  first  order  calculations  for  a  satellite  structure  design,  axial  and  lateral 
loading,  natural  frequency,  and  deformation  analysis  was  performed  on  all  seven  of  the 
satellite  architectures  for  this  study  (see  System  Synthesis). 


15.5.3.6.1  Axial  and  Lateral  Bending  Loads 

The  analysis  of  axial  and  lateral  bending  loads  can  be  best  visualized  with  Figure  15-33 
below. 
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Pavioad 


Figure  15-33:  Axial  and  Lateral  Loading  on  a  Satellite  Bus 


To  begin  the  structural  analysis,  the  team  investigated  the  optimal  beam  diameter  and 
thickness.  If  one  knows  the  critical  buckling  conditions  (Per),  the  length  of  the  beams  (L), 
the  number  of  sides,  and  the  structure’s  material  properties  (E),  one  can  calculate  the  area 
of  inertia. 


(Eqn  15-17) 


From  this  one  can  model  the  beam’s  radius  and  thickness  to  obtain  the  lightest  structure, 
satisfying  the  axial  and  lateral  loading  conditions  (see  Appendix  B).  Because  each  Modsat 
design  will  produce  different  loading  conditions,  these  calculations  give  the  designer  a 
starting  point. 

With  this  analysis  complete  and  some  preliminary  modeling,  the  team  selected  a 
octagon  structure  for  all  structural  designs.  Except  for  MIDTAC-23  all  the  remaining 
satellite  designs  were  constructed  with  beam  diameters  of  4  cm  and  thickness  of  1  cm. 
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Those  parameters  as  well  as  the  other  key  characteristics  of  the  Modsat  bus  structure,  are 
presented  in  Table  15-25  below. 


Table  15-25:  Structural  Design  Speciflcations 


Beam 

diameter 

(cm) 

Beam 

thickness 

(cm) 

Structure 
mass  (Kg) 

Structure 
height  (cm) 

Plate 

placement 

(cm) 

MAXTAC 

4 

1 

66.42 

71 

21,50 

MIDTAC 

4 

1 

65.75 

68 

18,47 

LOWTAC 

4 

1 

64.62 

63 

13,42 

MAXTAC-N 

4 

1 

65.97 

69 

21,63.8 

MIDTAC-N 

4 

1 

65.3 

66 

18,60.8 

LOWTAC-N 

4 

1 

64.17 

61 

13,55.8 

MIDTAC-23 

5 

1.5 

86.80 

68 

18,47 

With  these  structural  designs  known  the  next  step  was  to  evaluate  them  for  critical 
loading  discussed  above  and  bending  stresses  (Ob)  and  equivalent  axial  loading  (Peq) 
shown  below: 

(Eqn  15-18) 
(Eqn  15-19) 

Where 

Ob.’  Bending  stress 
M:  Bending  moment 
c:  Distance  from  neutral  axis 
I:  Area  of  inertia 
Peq:  Equivalent  axial  load 
Per:  Critical  buckling  load 
R:  Radius  of  the  satellite  bus 


a. 


Me 


P=P 

eq  cr 
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Equivalent  axial  loading  (Peq),  which  includes  axial,  lateral,  and  bending  loads,  is  a 
measure  of  how  much  a  loading  a  structure  can  withstand  before  buckling.  Peq  will  be  the 
primary  measure  for  ensuring  satellite  structural  integrity  during  launch. 

Since  these  relationships  are  incorporated  in  the  Modsat  model,  the  model  was  used  to 
evaluated  each  of  the  seven  designs.  All  designs  exceeded  the  structural  limits  of 
aluminum  alloy  7076-T6  and  the  494  pound  loading  conditions  (at  satellite  eg).  The 
results  are  shown  below. 


Table  15-26:  Structural  Results  of  the  Modsat  Designs 


Critical  Load  (Per) 
(1x10^  N/m^) 

Bending  stress  (Gb) 
(1x10®  N/m^) 

Equivalent  Load  (Peq) 
(1x10^  N/m^) 

MAXTAC 

7.214 

6.044 

7.453 

MIDTAC 

7.885 

5.825 

8.111 

LOWTAC 

9.230 

5.465 

9.437 

MAXTAC-N 

7.651 

6.037 

7.877 

MIDTAC-N 

8.385 

5.820 

8.599 

LOWTAC-N 

9.867 

5.495 

10.060 

MIDTAC-23 

11.460 

1 

4.107 

11.820 

Aluminum 

7076-T6 

N/A 

1 

480 

N/A 

Max  Load 

4.576 

N/A 

4.576 

15.5.3.6.2  Natural  frequencies 

A  determination  of  the  natural  frequency  is  critical,  in  order  to  ensure  that  the 
structure  will  not  resonate  at  a  frequency  equal  to  or  less  than  the  natural  frequency  of  the 
launch  vehicle.  In  this  case,  the  natural  frequency  of  the  Pegasus  is  18  Hz  in  the  lateral 
and  axial  directions  from  Table  18-9  in  SMAD  (Loftus  and  Teixeira,  1992:688).  The 
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governing  natural  frequency  equations  from  Figure  1 1-41  in  SMAD  are  shown  below 
(Doukas  and  others,  1992:454).  Both  equation  are  measured  in  Hertz  (Hz). 


natural  lateral  frequency  =  0.276. 


'  El 
mL^ 


(Eqn  15-20) 


natural  axial  frequency  =  0.160 


Where 


E:  Modulus  of  Elasticity 
m:  Mass  per  unit  length 
L:  Length  of  beam 
I;  Area  of  inertia 
A:  Cross-sectional  area 


(Eqn  15-21) 


Again,  the  Modsat  model  was  used  to  determine  the  natural  frequency  for  all  of  the 
Modsat  design.  All  exceeded  the  axial  and  lateral  frequency  for  the  Pegasus  launch 
vehicle.  The  results  are  shown  below  in  Table  15-27. 


Table  15-27;  Natural  Structural  Frequencies  for  the  Modsat  Designs 


Lateral  Frequency 
(Hz) 

Axial  Frequency 
(Hz) 

MAXTAC 

19.81 

403 

MIDTAC 

21.26 

404.7 

LOWTAC 

24.11 

407.7 

MAXTAC-N 

20.76 

404.1 

MIDTAC-N 

22.33 

405.9 

LOWTAC-N 

25.33 

407.5 

MIDTAC-23 

19.16 

476.8 

Pegasus  Launch  Vehicle 

18 

18 
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15.5.3.7  Conclusions 


This  study  has  eliminated  numerous  satellite  design  alternatives.  The  best  Modsat 
design  is  an  octagon  “polysat”  constructed  to  fit  on  the  Pegasus  XL,  38”/without  HAPS. 
The  Modsat  satellite  design  also  includes  mounting  plates  to  enhance  modularity  and 
supportability  of  the  mission  module. 

All  of  the  Modsat  designs  in  Table  15-25  exceeded  the  axial  and  lateral  launch  loading 
limits  Avhile  satisfying  the  natural  frequency  requirements  for  the  Pegasus  XL.  Although 
this  study  provided  some  preliminary  structural  results,  fiirther  modeling  is  necessary  to 
determine  if  these  Modsat  designs  will  meet  other  loading  requirements  not  discussed. 

15.5.4  Thermal  Control 

15.5.4.1  Introduction 

Thermal  design  begins  with  defining  its  purpose.  As  the  name  implies,  thermal 
design  is  concerned  with  constructing  a  thermal-control  subsystem  ...  to  maintain  all 
elements  of  the  spacecraft  system  within  their  temperature  limits  for  all  mission  phases” 
(McMordie,  1992:409).  In  every  satellite  design,  the  designer  must  consider  the  thermal 
impacts  due  to  the  sun,  the  earth,  and  internal  heat  generation.  Considering  each  of  these 
thermal  sources  is  important  to  ensuring  the  subcomponents  within  the  mission  module  or 
satellite  bus  operate  within  their  prescribed  temperature  ranges  shown  in  Table  15-28. 
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Table  15-28:  Typical  Spacecraft  Component  Design  Temperatures 


Component  or  subsystem 

Operating  Temperature 
(degrees  in  C) 

Survival  Temperature 
(degrees  in  C) 

Digital  electronics 

0  to  50 

-20  to  70 

Analog  electronics 

0  to  40 

-20  to  70 

Batteries 

10  to  20 

0to35 

Infi-ared  detectors 

-269  to -173 

-269  to  35 

Solid-state  particle  detectors 

-35  to  0 

-35  to  35 

Momentum  wheels,  motors,  etc. 

0  to  50 

-20  to  70 

Solar  panels 

-100  to  125 

-100  to  125 

Soiuce;  Wingate,  1994:433 


Just  as  the  table  suggests,  the  extent  of  thermal  analysis  depends  on  the  thermal  sensitivity 
of  the  satellite’s  subcomponents.  As  pointed  out  by  McMordie,  the  power  system  has  the 
greatest  impact  on  the  thermal  design  because  of  the  electrical  energy  being  dissipated 
throughout  the  satellite  and  the  tight  operating  temperature  limits  of  the  batteries 
(McMordie,  1992:411). 

15.5.4.2  Thermal  Design  and  Modeling 

Thermal  design  is  not  as  trivial  as  it  may  seem.  The  earth,  sun,  and  internal  power 
thermal  sources  vary  in  duration  and  intensity  with  respect  to  the  satellite.  Modeling  their 
thermal  variances  on  the  satellite  throughout  the  satellite’s  orbit  is  difficult  and  beyond  the 
scope  of  this  thermal  study.  Instead,  this  thermal  study  will  report  the  subcomponent 
thermal  sensitivity  results,  which  were  used  to  design  and  develop  the  interface  blanket  for 
the  satellite  bus/mission  module  interface.  Although  this  study  will  also  report  some 
preliminary  thermal  findings,  only  with  a  complete  and  more  accurate  thermal  model  can 
further  research  be  conducted. 
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Thermal  control  can  be  accomplished  either  actively  or  passively,  or  both.  The  team 
decided  from  the  start  to  maximize  the  use  of  passive  systems  to  minimize  cost,  weight, 
and  the  power  required  of  active  systems  (McMordie,  1992:413).  Since  “...preliminary 
mission  design  indicates  that  unmanned,  low-Earth  orbit  spacecraft  can  be  controlled 
passively”,  active  systems  were  not  investigated  in  this  study  (McMordie,  1992:413). 
Therefore,  passive  systems  such  as  thermal  coatings,  thermal  insulation,  and  space 
radiators  are  ideal  devices  for  meeting  thermal  constraints  in  a  satellite  design  (McMordie, 


1992:411). 

The  team’s  analysis  began  with  defining  the  thermal  environment  of  Modsat.  This 


environment,  shown  below  in  Figure  15-34,  consists  of  four  heat  inputs/outputs. 


Mean  value  of 
Direcl  Solar  Flux 


Emitted 

Radiation 

Low-Earth 

^  Orbit  Spacecraft 


Figure  15-34:  Thermal-radiation  Environment  for  a  Typical  Spacecraft 


The  heat  energy  shown  by  the  arrows  is  transferred  through  radiation  and  is  governed 
by  the  Stefan-Boltzmaim  equation  shown  below. 
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(Eqn  15-22) 


H  =  aT'' 

H:  Heat  energy  emitted 

c:  Stefan-Boltzmann  constant  (5.67x10'*  WattsW  K)'* 

T :  Temperature  of  the  black  body 

The  Stefan-Boltzmann  equation  does  not  account  for  conduction,  the  transfer  of  heat 
energy  through  physical  contact  between  objects.  Together,  radiation  and  conduction 
considerations  make  up  the  extent  of  thermal  analysis.  Although  thermal  analysis  may 
appear  simple  and  straight  forward,  it  is  not.  Complete  thermal  analysis  of  a  satellite  is 
complex  because  the  designer  has  to  consider  all  of  the  following  thermal  considerations: 

-  Subcomponents  re-radiate  energy  to  one  another. 

-  Total  eclipse  times  of  satellite  depends  on  orbit’s  size,  inclination,  and  time  of  year. 

-  Subcomponents  are  made  of  different  materials,  exhibiting  varying  absorption  (alpha) 
and  emmissivity  (epsilon)  properties. 

-  Subcomponents  have  various  geometric  shapes,  and  may  reside  virtually  anywhere 
within  the  satellite. 

-  Subcomponents  generating  heat  may  have  varying  on  and  off  times,  and  they  may 
have  varying  power  levels  when  they  are  on. 

-  The  attitude  of  the  satellite  (Wingate,  1994:433) 

-  Solar  energy  varies  with  earth’s  elliptical  orbit  about  the  sun  (Wingate,  1994:440). 

If  a  designer  were  to  model  and  consider  all  the  thermal  conditions  above,  the  thermal 
analysis  would  become  very  difficult,  complex,  and  computer  intensive.  Thermal  analysis 
essentially  comes  down  to  determining  the  number  of  conditions  (variables)  a  designer 
wishes  to  track  during  the  satellite’s  orbit.  The  designer  must  also  consider  how  to  model 
the  satellite  and  its  subcomponents.  The  designer  could  model  the  entire  satellite  as  a  box, 
a  sphere,  or  a  cylinder  with  some  general  properties,  and  obtain  some  overall  satellite 
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thermal  approximations  (McMordie,  1992:443-445,460-465).  The  designer  could  go  a 
step  forther  and  model  the  temperature  fluctuations  for  each  subcomponent.  The  designer 
could  take  the  final  leap  and  use  finite-element  modeling,  analyzing  each  subcomponent  as 
a  collection  of  smaller  elements.  As  one  author  put  it,  “thermoelastic  analysis  with  finite- 
element  models  ...is  usually  the  best  approach”  (Lewis,  1992:305).  Regardless  of  what 
modeling  level  the  thermal  designer  decides  to  use,  knowledge  of  the  geometry  of  the 
satellite,  the  earth,  and  the  sun  is  still  the  basis  of  thermal  analysis.  The  designer  should 
also  keep  in  mind  the  "...geometry  of  a  spacecraft  is  generally  complex,  leading  to 
numerically  complex  analysis”  (McMordie,  1992:409), 

To  develop  a  first  order  thermal  model,  the  team  needed  to  reduce  the  complexity  of 
the  thermal  analysis.  This  started  with  making  assumptions  to  eliminate  a  number  of  the 
variables  already  mentioned.  Since  satellite-earth-sun  geometry  (Qer)  is  the  most 
challenging  consideration,  the  team  decided  to  consider  only  the  sun  (Qds)  and  earth  (Qet) 
angles  in  the  satellite’s  orbit.  Because  modeling  the  satellite’s  attitude  throughout  the 
orbit  is  a  major  undertaking,  the  team  assumed  the  satellite’s  attitude  was  fixed  in  inertial 
space.  The  sun  angle  was  modeled  using  the  Beta  (P)  angle  (see  Eqn  1-23)  for  the  entire 
orbit  around  the  sun  at  15  degree  increments. 

P  =  23  degrees  (earth’s  tilt)  +  orbit  inclination  (for  the  satellite)  (Eqn  15-23) 

The  earth  angle  was  assumed  constant  and  always  facing  the  top  of  the  satellite.  Although 
reflected  solar  radiation  (Qer)  is  a  major  radiation  contributor,  amounting  to  25-35%  of 
direct  sunlight,  it  was  not  considered  in  the  thermal  model  (McMordie,  1992:410).  Doing 
so  would  require  extensive  modeling  of  the  sun-earth-satellite  reflection  angles 
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throughout  the  satellite’s  orbit  and  the  earth’s  orbit  about  the  sun.  With  these 
assumptions  in  mind  the  team  used  equation  15-24  to  perform  the  thermal  analysis 
(Wingate,  1994:445); 

Qint  +  Qds  +  Qer  +  Qet  =  ctsAscTsc'^  (Eqn  15-24) 

Where: 

a:  Solar  absorptivity  of  the  subcomponent 

e:  IR  emittance  of  the  subcomponent 

o  =  5.67x10'*  W-m'^-K''*:  Stephan-Boltzmann  constant 

Fet:  Configuration  factor 

Hsu:  Solar  constant 

Het:  Earth’s  emitted  IR 

PAS  =  Area  vector*  sun  vector:  Projected  solar  area 

Asc;  Total  surface  area  of  component 

Qint:  Heat  output  of  the  subcomponent 

Qds  =  a*PAS*Hsu:  Incident  solar  energy  on  the  satellite 

Qer:  Reflected  solar  energy  (sun-earth-satellite) 

Note:  Not  considered  in  the  Modsat  model 
Qet  =  e*Fet*Asc*Het:  Earth  emitted  radiation 
Tsc:  Temperature  of  subcomponent 


Before  calculating  the  amount  of  direct  incident  radiation  on  each  subcomponent,  the 
model  converts  the  geometric  shape  of  each  subcomponent  in  the  satellite  into  a  box  shape 
as  shown  below  in  Figure  15-35. 


Figure  15-35:  Conversion  to  Box  Shapes  by  the  Model 
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This  technique  within  the  thermal  algorithm  reduces  the  number  of  surfaces  from  several 
to  six,  but  at  the  expense  of  introducing  surface  area  and  vector  (facing  direction)  errors. 
Once  the  thermal  model  has  determined  the  sun  angles  throughout  the  year  plus  one 
eclipse  period,  subcomponent  temperature  changes  are  calculated  using  equation  15-24. 
The  resulting  thermal  information  is  then  stored  to  be  graphically  displayed  as  shown  in 
the  next  section. 

Through  thermal  modeling,  the  team  was  also  able  to  highlight  those  subcomponents 
more  sensitive  to  thermal  changes.  The  modeling  analysis  also  showed  that  a  majority  of 
the  subcomponents  are  sensitive  to  eclipse  periods.  Therefore,  any  follow-on  thermal 
modeling  should  consider  this  phase  of  Modsat’s  orbit. 


15.5.4.3  Thermal  Properties  of  a  Satellite  Bus 

To  obtain  a  high  level  of  understanding  of  these  thermal  effects  on  the  Modsat 
structure,  the  team  created  a  theoretical  cylinder  representing  the  height  and  diameter  of 
MIDTAC.  This  cylinder,  constructed  of  7075-T6  mill  aluminum,  was  run  through  the 
Modsat  model  with  a  350  Km,  96.85  degree  inclined  sun-synchronous  orbit. 

Using  the  typical  structures  temperature  of  -45  to  65  “C  (228  to  338  °K)  from 
McMordie,  the  Modsat  model  calculated  and  graphed  the  temperature  variations  of  the 
satellite  bus  throughout  the  year  (McMordie,  1992:410).  The  red  and  blue  lines  depict  the 
satellite’s  upper  and  lower  temperature  limits. 
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Figure  15-36:  MIDTAC  Bus  Temperature  Changes  During  the  Year 


This  graph  provided  the  team  a  rough  approximation  of  the  thermal  conditions  the 
hypothetical  MIDTAC  satellite  bus  could  experience.  Although  the  bus  exceeds  the  upper 
operating  limit,  the  data  is  based  on  a  first  order  calculation  and  should  not  be  accepted 
without  further  analysis.  A  more  accurate  model  is  necessary  to  complete  the  thermal 
analysis. 


15.5.4.4  Designing  Thermal  Interface  Plate  Protection 

To  support  the  bus/mission  module  design  discussed  in  the  structure’s  trade  study,  the 
team  designed  a  thermal  blanket  constructed  of  woven  insulation  to  be  placed  directly 
below  the  top  interface  plate,  as  shown  in  Figure  15-37.  This  blanket  (shown  in  green) 
will  reduce  the  heat  transfer  between  the  bus  (shown  in  light  blue)  and  the  mission  module 
(shown  in  blue)  by  restricting  temperature  changes  between  the  two  structures. 
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Figure  15-37:  Thermal  Protection  of  the  Satellite  Bus/Mission  Module  Interface 

To  restrict  heat  transfer  between  the  bus  and  the  mission  module,  the  designer  must 
apply  the  thermal  conductivity  equation  shown  below. 

Q  ^  ^  ^insulation^  ^^  ^5) 

L  L 

Where 

Q  dot:  Heat  flow 

k;  Thermal  conductivity  of  materials 
A:  Area  of  heat  flow 
T:  Temperature 

With  this  equation,  the  thermal  analysis  between  the  mission  module,  the  woven 
insulation,  and  the  satellite  bus  can  be  conducted.  The  goal  is  to  minimize  the  heat 
transferred  between  them.  The  kaiuminum  and  kinsuiation  terms  represent  the  thermal 
conductivity  of  aluminum  and  woven  insulation;  the  lower  the  number,  the  better  the 
material  will  hinder  heat  flow.  The  area  to  which  the  heat  transfers  is  designated  A,  and  L 
is  the  distance  the  heat  travels  fi’om  one  medium  to  another.  To  begin  the  analysis,  one 
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starts  with  T i,  the  satellite  bus  temperature,  and  work  backwards  to  obtain  T3,  the 
temperature  of  the  mission  module.  This  preliminary  analysis  concentrated  on  the  100  °C 
differential  of  a  typical  bus  structure  as  the  baseline.  Depending  on  the  temperature 
required  by  the  mission  module,  the  minimum  thickness  of  the  woven  insulation  to 
preclude  a  15  degree  Celsius  change  between  either  the  plate  or  the  mission  module  can  be 
calculated  (see  calculations  in  Appendix  C,  Thermal).  For  the  Modsat  the  team  designed 
for  a  4  cm  thick  interface  blanket. 

15.5.4.5  Future  Thermal  Studies 

The  next  generation  thermal  model  should  break  the  satellite  into  thousands  of 
interconnecting  nodes  through  some  three-dimensional  mapping  scheme.  Each  node  in  the 
three-dimensional  lattice  would  carry  the  attributes  of  position,  local  material  properties, 
and  associations  with  neighboring  nodes.  This  idea  comes  partially  from  Wingate,  who  in 
fact  suggested  dividing  up  the  satellite  into  50  nodes,  which  are  actually  50  separate 
surface  areas  making  up  the  entire  surface  of  the  satellite  (Wingate  1994:445-446).  Each 
small  piece  would  then  be  modeled  for  conduction  and  radiation  thermal  transfer. 

15.5.4.6  Conclusion 

Although  the  thermal  model  is  far  from  being  able  to  give  the  team  an  accurate 
representation  of  the  thermal  conditions  the  subcomponents  will  experience,  it  does 
highlight  the  level  of  sensitivity  of  the  subcomponents.  The  first  order  thermal  analysis 
also  highlighted  the  need  for  further  thermal  modeling  during  eclipse  periods. 

The  addition  of  a  interface  thermal  blanket  should  prove  useful  for  ensuring  the 
heat  flow  between  the  satellite  bus  and  mission  module  is  kept  to  a  minimum.  However, 
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the  thickness  of  this  blanket  is  contingent  upon  the  thermal  variations  of  the  mission 
module  and  satellite  bus.  If  the  thermal  variations  between  them  are  great,  the  interface 
thermal  blanket  may  be  too  large  taking  up  valuable  volume. 

Because  many  thermal  design  options  are  contingent  on  knowing  the  overall 
satellite  configuration,  thermal  trade-off  studies  should  continue  throughout  all  phases  of 
the  satellite  design. 


15.5.S  Telemetry,  Tracking,  Commanding,  Communications,  and  Data  Handling 
15.5.5.1  Communications  System 

The  communications  system  for  the  satellite  bus  consists  of  the  equipment 
necessary  to  relay  commands  to  the  vehicle  from  the  ground  and  to  send  health,  status, 
and  in  some  cases,  payload  data,  from  the  satellite  to  the  ground.  It  is  not  uncommon  for 
a  satellite  bus  to  employ  two  separate  communications  systems.  One  communications 
system  nominally  operates  at  a  low  data  rate  while  the  other  operates  at  a  high  data  rate. 
This  configuration  provides  two  different  means  of  retrieving  satellite  data  and 
commanding  the  vehicle.  Operationally,  the  low  data  rate  system  is  used  to  retrieve 
spacecraft  health  and  status  information  and  to  send  commands  to  the  satellite  bus.  The 
Air  Force  Satellite  Control  Network  provides  this  function  to  satellite  programs  such  as 
Fleet  Satellite  Communications  (FLTSATCOM),  Defense  Satellite  Communications 
System  (DSCS),  Global  Positioning  System  (GPS),  and  the  Defense  Support  Program 
(DSP)  (Muolo,  1993:178-183).  The  high  data  rate  package  is  nominally  used  to  receive 
mission  module  data  and  to  send  commands  to  the  mission  module.  In  contingency 
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situations  where  one  communications  system  is  rendered  inoperable,  the  alternate 
communications  package  can  be  used  to  receive  spacecraft  data  and  to  command  the 
vehicle.  Vehicle  equipment  required  to  operate  both  systems  is  the  same.  This  equipment 
includes  an  antenna,  a  diplexer  (allows  routing  to  and  from  the  antenna),  amplifiers,  filters 
and  demodulator/modulator. 


Specific  Functions  of  the  Communications  Subsystem  ^ 


Carrier  Tracking 

-  2- way  coherent  communication  (downlink  is  ratio  of  uplink  frequency) 

-  2  way  non-coherent  communications 
- 1  way  communications 

Command  reception  and  detection 

-  Acquire  and  track  uplink  carrier 

-  Demodulate  carrier  and  subcarrier 

-  Derive  bit  timing  and  detect  data  bits 

-  Resolve  data-phase  ambiguity  if  it  exists 

-  Forward  command  data,  clock,  and  in-lock  indicator  to  the  subsystem  for  command  and 
data  handling 
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(continued) 


Telemetry  modulation  and  transmission 

-  Receive  telemetry  data  streams  from  the  command  and  data  handling  subsystem  or  data 
storage  device 

-  Modulate  downlink  subcarrier  and  carrier  with  mission  telemetry 

-  Transmit  composite  telemetry  and  range  signal  to  Earth  or  relay  satellite 


Ranging 

-  Detect  and  transmit  ranging  pseudorandom  code  or  ranging  tone  signals 

-  Retransmit  either  phase  coherently  or  non-coherently 


Subsystem  operations 

-  Receive  commands  from  the  subsystem  for  command  and  data  handling 

-  Provide  health  and  status  telemetry  to  the  C&DH  subsystem 

-  Perform  antenna  pointing  for  any  antenna  requiring  beam  steering 

-  Perform  mission  sequence  operations  per  stored  software  sequence 

-  Autonomously  select  omni  antenna  when  spacecraft  attitude  is  lost 
-Autonomously  detect  faults  and  recover  communications  using  stored  software  sequence 


The  conventional,  or  nominal,  design  of  a  command  and  data  handling  (C&DH) 


system  requires  both  the  command  and  telemetry  equipment  plus  associated  data  lines  be 


hard-wired  together.  The  command  decoder,  telemetry  format  unit,  and  controller  are 
usually  contained  within  a  single  unit  called  the  command  and  telemetry  unit.  The 


command  decoder  validates  the  command  message  and  decodes  the  commands  if  the 


message  is  valid.  The  command  decoder  receives  both  bi-level  commands  (on/off 
commands)  and  serial  (data)  commands.  Bi-level  commands  are  sent  to  a  command 


matrix,  which  is  a  board  consisting  of  horizontal  and  vertical  addresses.  For  a  given 
horizontal  and  vertical  address,  a  signal  is  routed  to  a  subsystem  to  enable  or  disable  a 
function.  Serial  commands  are  used  for  functions  that  are  critical  to  the  operation  of  the 


250 


subsystem  and  possibly  the  satellite.  Data  is  routed  directly  to  a  subsystem  command 
buffer.  That  data  is  then  read  out  in  telemetry  to  verify  that  the  data  was  loaded  correctly 
before  an  executable  command  is  sent. 

Subsystem  telemetry  data  is  routed  to  the  telemetry  format  unit.  The  analog  data 
is  usually  converted  to  digital  format  before  it  is  sampled,  commutated  with  other  digital 
data,  and  the  result  is  placed  into  a  telemetry  masterframe.  A  telemetry  masterffame 
contains  all  of  the  satellite  data  and  consists  of  telemetry  mainframes  and  subframes. 
Subframes  contain  small  amounts  of  satellite  data.  These  subframes  are  combined  with 
other  subframes  to  develop  a  telemetry  mainframe  of  data.  Telemetry  mainframes  are 
large  amounts  of  satellite  data  that  are  combined  with  other  mainframes  to  create  a 
masterframe  of  telemetry  data.  The  telemetry  masterframe  contains  all  of  the  satellite 
data. 

All  of  these  functions  operate  under  the  direction  of  the  controller.  The  controller 
maintains  the  satellite  timing  and  determines  command  priority  if  more  than  one 
commanding  system  is  in  use. 
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Figure  15-38:  Nominal  Style  of  Command  and  Data  Handling 


A  possible  Command  and  Data  Handling  architecture  involves  the  use  of  a  Satellite 
Operating  System  (SOS),  which  enables  an  extremely  broad  range  of  modularity.  Using 
software,  the  main  processor  can  perform  the  process  of  decryption/encryption,  command 
controller  functions,  and  data  compression  algorithms.  Subsystem  interfaces  route 
through  the  Interrupt  Request  (IRQ)  processor,  which  handles  traffic  deconfliction  and 
prioritization.  Instead  of  conventional  hard-wired  interfaces  among  subsystems,  modular 
subsystems  route  their  fimctional  requests/needs  through  the  central  processor,  which 
prioritizes  subsystem  requirements  in  view  of  overall  satellite  operations.  Subsequently, 
appropriate  action  is  directed  to  the  proper  subsystem  in  a  format  understood  by  the 
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modular  subsystem.  In  essence,  SOS  provides  an  interface  to  allow  vastly  different 
subsystems  to  communicate  to  each  other  and  work  together  through  a  baseline  structure. 
Further  advantage  is  gained  by  the  ability  to  change  SOS  on  the  fly  while  the  satellite  is  in 
orbit,  through  the  uploading  of  new  software  to  the  central  processor.  A  block  diagram  is 
shown  in  Figure  15-39: 


Figure  15-39:  Proposed  Style  of  Command  and  Data  Handling 
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15.5.5.2  Subsystem  Level  Tradeoff 


A  subsystem  design  tradeoff  was  performed  between  the  nominal  C&DH  design 
and  the  Satellite  Operating  System.  The  Satellite  Operating  System  was  selected  as  the 
baseline  for  the  satellite  bus  design.  This  system  was  selected  over  the  conventional 
means  because  the  SOS  offers  more  advantageous  characteristics.  The  SOS  will  be  a 
lighter-weight  design  because  software  can  replace  some  of  the  subsystem  hardware. 

For  example,  software  code  can  replace  the  command  matrix  board,  the  encryptor,  and 
the  decryptor  hardware.  SOS  offers  yet  another  advantage.  SOS  has  a  means  for 
modifying  the  downlink  of  health  and  status  data  in  a  more  user  ffiendly-manner. 

Software  code  can  permit  the  formatting  of  satellite  telemetry  data  in  such  a  manner  that 
telemetry  data  can  be  accessed  by  ground  users  in  much  the  same  way  that  users  access 
the  internet. 

Another  reason  for  the  selection  of  SOS  is  that  it  is  modular  in  nature.  The 
modular  characteristics  of  the  system  allow  for  easy  addition  or  removal  of  components 
to  the  C&DH  subsystem.  By  having  IRQ  checks,  the  system  could  operate  with  or 
without  the  additional  components.  If  a  component  is  not  connected  to  the  bus,  the  SOS 
would  be  aware  of  this  status.  If  a  component  is  added,  “driver”  software  would  be 
resident  within  the  SOS  program  that  checks  to  see  if  the  added  component  is  available  for 
operation.  Another  advantage  of  selecting  SOS  is  that  the  C&DH  code  could  be  modified 
while  the  spacecraft  is  in  flight.  While  some  spacecraft  permit  Attitude  Control  Subsystem 
modification,  C&DH  subsystem  modification  is  not  an  option  on  most  current  satellite 
designs. 
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15.5.5.3  Data  Handling 


Instead  of  using  conventional  methods  for  data  uplink/downlink,  SOS  can  take 
advantage  of  data  formatted  in  Hyper  Text  Markup  Language  (HTML),  and  more  recently 
JAVA,  which  are  standardized  protocols  for  handling  multimedia  over  the  internet.  This 
approach  allows  a  user  in  a  combat  theater,  using  a  laptop  connected  to  a  small,  portable 
communications  dish,  to  receive  data  from  the  satellite.  A  forerunner  to  this  type  of 
ground  station  is  resident  at  the  Naval  Post  Graduate  School  in  Monterey,  California 
(Bible,  1995).  The  user  could  review  the  data  at  wiU  with  an  internet  browser  and  be 
empowered  to  act  more  efficiently  due  to  timely  information  flow.  If  the  satellite  is 
overhead  and  thus  able  to  communicate  for  five  to  ten  minutes  during  a  pass,  data  can  be 
dumped  to  a  CD  ROM.  The  user  can  alter  the  amount  of  data  received  to  the  level 
needed,  providing  a  "data-on-demand"  flow  instead  of  working  with  the  full  amount  of 
data  downlinked  from  the  satellite.  Use  of  "data-on-demand"  leads  to  more  efficient  use 
of  communications  bandwidth.  Security  plug-ins  to  the  browser  will  handle  Department 
of  Defense  encryption  needs. 

In  the  event  a  satellite  has  served  its  purpose  and  is  no  longer  needed  by  personnel 
in  a  given  military  theater,  security  plug-ins  can  be  deactivated  on  the  fly,  and  the  satellite 
can  serve  commercial  purposes  or  even  other  military  needs.  This  method  of  data 
handling  enables  the  satellite  to  adapt  to  changing  needs  to  suit  multiple  purposes,  which 
means  greater  efficiency  and  far  better  economical  use  of  the  satellite  than  current 
methods. 

In  essence,  the  paradigm  of  a  satellite  as  another  internet  node  has  far  reaching 
implications.  Various  payload  imagery  and  communications  can  be  used  rather  efficiently 
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by  a  user  in  the  field  with  the  point-and-click  ease  of  a  web  browser.  Satellite  intelligence 
can  be  displayed  in  a  user  fiiendly  format  in  near  real  time  along  with  other  multimedia, 
such  as  a  voice  message  attached  to  the  most  recent  imagery,  giving  the  field  commander 
in  another  remote  location  the  user's  perspective  of  a  certain  objective.  Furthermore,  the 
user  can  load  scheduling  plans  for  any  connectivity  desired  with  the  satellite  by  uplinking 
desired  parameters  to  the  satellite  as  it  passes  overhead,  or  even  via  a  "bent  pipe"  analogy 
(Klements,  1992)  when  the  satellite  is  not  in  view.  Range  scheduling  is  thus  coordinated 
between  user  and  satellite  instead  of  through  traditional  means. 

15.5.5.4  Subsystem  Inteifaces 

The  Command  and  Data  Handling  subsystem  interfaces  with  multiple  subsystems 
at  varying  data  rates;  refer  to  Figure  15-40.  It  must  handle  payload  telemetry  and 
commanding,  and  provide  ‘store  and  forward’  capability.  Sensor  information  gives  the 
central  processor  positioning  data,  which  is  then  correlated  with  attitude  control 
(propulsion  subsystem).  C&DH  must  be  able  to  interpret  command  formats  from  the 
various  subsystems,  reply  to  subsystems  in  the  appropriate  format,  as  well  as  format 
telemetry  and  encrypt  as  necessary  for  downlink  to  ground  stations. 
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Sensor  Data: 

--  Star  Tracker 
--  Horizon 


Power  Status: 

Data  Rate  <  1  kbit/sec 


Position  Information: 
Data  Rate  <  1  kbit/sec 


Thermal  Control 


Housekeeping  Commands  & 
Thermal  Control  Feedback: 
Data  Rate  <  1  kbit/sec 


Command  Fimctions  and 
Telemetry: 

10  kbit/sec  <  Data  Rate  <  500 
Mbit/sec 


X 


,TOwer: 

~  Main  Buss  Voltage 
--  Battery  Status 
—  Solar  Panel  Status 


Housekeeping  Commands  &  ACS 
Status  Feedback: 

Data  Rate  <  1  kbit/sec 


z 


(  Attitude  Control  System  (ACS): 
--  Attitude  Thruster  Firing 
-  Momentum  Wheels 
c-  Reaction  Wheels 


Commands  to  Satellite  and  Formatted 
Telemetry  Information: 

1  kbit/sec  <  Data  Rate  <  2  Mbit/sec 


Payload 


Propulsion  Status: 
Data  Rate  <  1  kbit/sec 


,/^pulsion: 

—  Valve  (line)  status 

—  Tank  pressure 

—  Fuel  level 


Communications 

Uplink/Downlink 

. _ y 


Figure  15-40:  Command  and  Data  Handling  Interactions 
15.5.5.5  Design  and  Sizing 

15.5.5.5.1  C&DH  Design  Process 

To  design  a  satellite  bus  Command  and  Data  Handling  subsystem,  the  designer 
must  understand  the  operation  of  the  subsystem  and  consider  many  different  aspects 
affecting  the  subsystem.  The  designer  must  also  understand  the  effects  these  different 
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aspects  have  on  mass,  cost,  and  power  of  the  components  used  in  the  construction  of  the 
subsystem.  Each  of  the  following  are  drivers  for  determining  subsystem  mass,  cost,  and 
power  consumption  of  the  C&DH  subsystem; 

•  Data  rates  are  required  for  interface  communications  between  subsystems,  which  also 
drives  required  clock  speed  and  processor  power. 

•  Crosslinking  to  other  satellites  drives  the  need  for  antenna,  power,  and  computer 
processor  capability. 

•  Data  storage  for  mission  modules  drives  the  need  for  on-board  computer  memory. 

•  The  available  time  for  data  downlink  drives  data  rate  requirements,  which  also  drives 
the  need  of  more  computer  processing  power. 

Other  issues  affect  the  means  for  downlinking  mission  module  data  to  the  ground 
station  or  other  user,  i.e.,  the  communications  aspect  of  the  C&DH  subsystem.  These 
issues  also  affect  mass,  cost,  and  power  requirements.  A  few  areas  of  concerns  are  listed 
below: 

•  Minimum  acceptable  signal  to  noise  ratio  (SNR)  drives  power  requirements  for  the 
data  downlink. 

•  Minimum  acceptable  SNR  for  received  signals  drives  the  gain  needed  on-board  the 
satellite. 

Using  this  information  as  a  background  for  starting  the  design,  it  is  necessary  that 
the  subsystem  engineer  understand  the  mission  of  the  satellite.  Additionally, 
communication  with  other  subsystem  experts  is  also  required.  This  interaction  ensures 
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that  subsystem  interface  requirements  are  met  and  that  C&DH  system  is  designed 
correctly  to  perform  its  intended  mission. 

There  are  many  issues  affecting  the  design  of  a  Command  and  Data  Handling 
subsystem.  Table  15-30  provides  an  outline  for  the  steps  involved  in  this  process. 


Table  15-30:  Steps  for  Designing  C&DH  System 


Step  ’  ^  . 

[a]  Obtain  data  rates  for  payload, 
subsystem  interfaces,  and 
communication  uplink/downlink 
and  crosslink 

Receive  information  on  mission  module;  get 
information  on  satellite  bus;  understand 
communication  frequencies,  bandwidths,  and  secure 
transmission  requirements 

[b]  Prepare  command  list  and 
telemetry  list 

Both  of  which  yield 

Understand  minimum  telemetry  points  for  satellite 
health,  and  interfaces  needed  to  provide  commands 
to  satellite  subsystems 

[c]  Processor  power  and  memory 
requirements 

Understand  minimum  processor  power  to  handle 
maximum  data  rates  for  communication  and 
housekeeping,  along  with  minimum  memory 
capacity  for  store  and  forward 

Which  yields 

[d]  Overall  processing 
requirements 

Examine  need  for  encryption,  decryption, 
sequencing,  and  processing  of  commands  and 
telemetry 

Which  leads  to 

[e]  Selection  of  equipment 

Understand  Commercial  Off  the  Shelf  (COTS) 
equipment,  cost,  size,  mass,  and  Mean  Time 

Between  Failures  (MTBF) 
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-Step 


What’s  Involved 


If  Mission  Module  Data  is  to  be 

Downloaded: 

[f]  Obtain  bandwidth  and  carrier 
frequencies  for  uplink/downlink, 
along  with  acceptable  SNR  and 
access  scheme 

Establish  power  budget  for  communications  and 
understand  necessary  footprint 

Which  yields 

[g]  Data  for  link  budget 

Estimate  atmospheric  attenuation,  noise,  and 
interference.  Perform  link  budget  calculations. 

Which  leads  to 

[h]  Sizing  communication  system 

Select  antenna  configuration,  calculate  size,  and 
estimate  mass.  Estimate  transmitter  mass  and 
power.  Obtain  cost  figures. 

Table  15-31  provides  a  parametric  estimation  for  mass,  power  and  size  of  a  C&DH 
subsystem  (Wertz  and  Larson,  1992:390).  Similarly,  data  has  been  collected  on  the  cost 
and  reliability  factors  for  C&DH  subsystems.  This  information  is  displayed  in  Table  15-32 
(Wertz  and  Larson,  1992:389). 


Table  15-31:  Estimation  of  C&DH  Size,  Weight,  and  Power 


Simple  ^ 

Typical  ■ 

Complex 

Size  (cm^3) 

Command  only 

1500-3000 

2000  -  4000 

5000  -  6000 

Telemetry  only 

1500-3000 

4000  -  6000 

9000  -  10000 

Combined  systems 

2500  -  6000 

6000  -  9000 

13000-  15000 

Weight  (kg) 

Command  only 

1.5 -2.5 

1.5  -3.0 

4.0 -5.0 

Telemetry  only 

1.5 -2.5 

O 

6.5  -7.5 

Combined  systems 

2.75  -  5.5 

4.5 -6.5 

9.5  -  10.5 

Nominal  Power 

Command  only 

2 

2 

2 

(watt) 

Telemetry  only 

5-10 

10-16 

13-20 

Combined  systems 

7-12 

13  -  18 

15-25 
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Table  15-32:  Reliability  and  Cost  Data  for  C&DH  Subsystem 


Requirement 

Constraint 

Complexity 

Simple 

T  •  1 

1  ypical 

Complex 

Reliability-  Class  B  Parts 
Single  String 

Redundant 

0.8233 

0.9875 

0.7610 

0.9736 

Reliability-  Class  S  Parts 
Single  String 

Redundant 

0.9394 

0.9987 

0.9083 

0.9964 

0.8285 

0.9829 

Costs 

Class  B  Parts 

Class  S  Parts 

100% 

400-500% 

100% 

400-500% 

i 

1 

100% 

400-500% 

Modeling  software  has  been  developed  to  take  advantage  of  the  information 
presented  in  Table  15-31.  Through  the  use  of  graphical  user  interfaces,  the  user  has  the 
option  of  designing  a  subsystem  by  its  parts  (command  only  and  telemetry  only)  or  as  an 
integrated  system.  The  user  can  also  specify  the  desired  level  of  complexity  to  design  into 
the  satellite  bus.  The  code  allows  the  user  to  enter  the  known  information  about  the 
subsystem  design.  The  unknown  parameters  are  then  calculated  using  an  interpolation 
method.  For  instance,  if  the  designer  enters  the  weight  of  a  command  component,  the 
corresponding  size  and  required  power  are  calculated  and  displayed. 


15.5.5.6  Component  Selection 

One  of  the  goals  of  the  study  was  to  use  commercial  off  the  shelf  (COTS) 
components  where  possible.  Information  had  to  be  gathered  on  the  commercially 
available  products  before  component  selection  could  begin.  Two  of  the  companies  that 
responded  to  our  information  request  were  Cincinnati  Electronics  and  Aydin  Vector. 
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These  companies  specialize  in  components  compatible  to  both  the  Air  Force  Satellite 
Control  Network’s  Space  Ground  Link  System  and  NASA’s  Ground-Space  Tracking  and 
Data  Network.  Another  company  that  responded  was  Honeywell.  Each  company  sent  a 
catalog  describing  the  performance  and  physical  characteristics  of  their  products.  It 
should  be  mentioned  that  the  team  was  not  able  to  gather  component  price  information 
from  any  of  the  vendors. 

Components  from  other  satellite  programs  were  also  considered.  The  Jet 
Propulsion  Laboratory  (JPL)  provided  the  team  with  a  Flight  Hardware  Survey  that 
included  a  database  of  the  components  used  on  JPL  programs.  The  Clementine  Program 
was  also  examined  for  Command  and  Data  Handling  components.  The  Clementine 
Program  incorporated  products  considered  to  be  state  of  the  art.  The  benefit  of  using 
Clementine’s  products  is  that  these  components  are  generally  smaller  and  lighter,  and 
provided  better  performance  than  other  commercial  off  the  shelf  products. 

The  Command  and  Data  Handling  components  chosen  for  the  generic  satellite  bus 
design  were  primarily  rated  on  their  performance-to-mass  ratios.  Cost  was  not  a  driving 
factor  because  component  prices  were  not  available.  Discussions  with  satellite  designers 
and  engineers  such  as  Richard  Warner  of  Aero  Astro,  Dave  Everett  of  NASA/Goddard 
Space  Fhght  Center,  and  Joel  Hagan  of  Phillips  Laboratory’s  MightySat  Program, 
revealed  that  Command  and  Data  Handling  is  one  of  the  most  critical  subsystems  on-board 
the  satelhte.  Without  the  proper  functioning  of  this  subsystem,  the  mission  of  the  satellite 
would  be  lost.  With  this  in  mind,  it  was  decided  that  only  space-rated  products  would  be 
used  in  the  design  of  this  subsystem. 
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Other  factors  were  considered  in  the  selection  of  components.  A  requirement  for 
the  transceiver  and  antenna  was  that  they  must  be  compatible  with  the  Space  Ground  Link 
System.  A  small  Cincinnati  Electronics  transceiver,  component  number  TTC-307/702, 
was  selected  for  the  team’s  satellite  bus  design  because  the  device  operated  using  the  Air 
Force  Satellite  Control  Network  frequencies.  The  amount  of  memory  provided  by  a  data 
storage  device  was  also  an  important  factor  since  the  satellite  needs  the  capacity  to  store 
both  mission  module  data  and  state  of  health  data.  The  team  selected  the  Clementine 
Program’s  data  storage  device  because  it  provided  2  Gigabytes  of  data  for  a  mass  of  only 
3.4  kilograms.  Other  data  storage  devices  considered  were  much  more  massive. 

Realizing  that  a  Satellite  Operating  System  architecture  would  require  strong  computing 
power,  the  team  chose  a  radiation  hardened,  32-bit,  high  speed  Reduced  Instruction  Set 
Computer  (RISC)  architecture  employing  Very  High  Speed  Integrated  Circuit  (VHSIC) 
technology.  This  computer  was  developed  by  Honeywell  for  the  Ballistic  Missile  Defense 
Office.  The  associated  controller  and  memory  modules  were  developed  under  sponsorship 
of  the  Naval  Research  Laboratory.  The  computer  and  its  associated  controller  were  light 
weight  and  extremely  powerful. 

Specific  components  were  not  selected  for  the  high  data  rate  communications 
system.  As  part  of  the  design  study,  it  was  decided  that  the  mission  module  developers 
would  provide  a  transceiver  and  antenna  for  the  satellite  bus.  This  arrangement  would 
provide  more  flexibility  for  the  mission  module.  Interface  data,  power,  mass,  and  size 
requirements  would  be  provided  to  the  mission  module  developers  to  assure  compatibility 
with  the  Satellite  Operating  System.  In  the  concept  of  operations,  the  use  of  the  Satellite 
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Operating  System  would  allow  easier  integration  of  a  high  data  rate  communications 
system. 


15.5.6  Electrical  Power 

This  section  of  the  report  discusses  the  design  of  the  electrical  power  subsystem 
(EPS)  for  Modsat.  The  following  areas  are  discussed: 

-  Problem  Definition 

-  Objectives 

-  Functional  Allocation 

-  Component  Design 

~  System  synthesis 
—  Tradeoffs  and  Decisions 
“  Design  Process 

-  Future  Efforts 

15.5.6.1  Problem  Definition 

The  EPS  must  perform  the  following  functions  (McDermott,  1992:391): 

•  Supply  a  continuous  source  of  power  to  all  spacecraft  loads 

•  Control  and  distribute  power  to  the  spacecraft 

•  Support  power  requirements  for  average  and  peak  loads 

•  Provide  converters  for  voltage,  as  required 

•  Provide  command  and  telemetry  capability  for  the  EPS 

•  Protect  the  spacecraft  against  failures  within  the  EPS 

•  Suppress  transient  bus  voltages  and  protect  the  subsystem  against  faults 

•  Provide  for  switching  to  redundant  spacecraft:  components 
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The  EPS  may  also  provide  for  reconditioning  the  batteries,  if  this  is  necessary. 

Many  elements  of  the  spacecraft  and  its  mission  affect  the  design  of  the  EPS. 
Among  them  are  (McDermott,  1992:392); 

•  Average  electrical  power  requirement 

Sizes  the  power  generation  system  and  possibly  the  energy-storage  system 

•  Peak  electrical  power  requirement 

Sizes  the  energy  storage  system  and  the  power-processing  and  distribution  equipment 

•  Spacecraft  design  life 

A  longer  mission  life  implies  extra  redundancy,  as  well  as  larger  batteries  and  arrays 

•  Orbital  elements 

Defines  incident  solar  energy,  eclipse/Sun  periods,  and  the  radiation  environment 

•  Spacecraft  configuration 

Affects  the  geometry  of  the  power  generation  system 

15.5.6.2  Objectives 

As  with  the  other  subsystems,  minimizing  cost  is  a  key  objective  in  the  design  of 
the  EPS.  An  emphasis  was  placed  on  using  readily  available,  relatively  inexpensive 
components.  Another  key  objective  is  minimizing  technological  risk.  All  spacecraft 
require  power,  and  advancements  in  space  power  technology  are  continually  made.  But  in 
light  of  the  objectives,  the  EPS  design  emphasized  the  use  of  proven  components  and 
architectures. 
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A  third  objective  which  had  a  large  impact  on  EPS  design  is  maximizing  flexibility. 
An  effort  was  made  to  accommodate  modularity  and  ease  of  integration,  since  each 
Modsat  spacecraft  could  be  a  different  configuration. 

But  of  course,  the  overriding  objective  for  EPS  design  is  to  provide  sufficient 
power  for  the  possible  range  of  mission  modules.  The  conclusion  one  must  draw  for  the 
generic  bus  is  that  its  EPS  accommodate  the  most  power-hungry  applications  planned  to 
be  flown  on  Modsat.  Thus,  a  large  amount  of  power  must  be  available  for  the  mission 
modules.  However,  not  all  configurations  will  require  all  the  available  power.  A  sound 
systems  engineering  approach  must  consider  the  impact  of  excess  power  (thermal  effects, 
inefficient  use  of  weight,  etc.). 

15.5.6.3  Functional  Allocation 

The  EPS  consists  of  four  major  functional  areas,  as  shown  in  Figure  15-41:  power 
source;  energy  storage;  power  distribution;  and  power  regulation  and  control. 


Source:  McDermott,  1992:391 

Figure  15-41;  Electrical  Power  Subsystem  Functions 


The  systems  engineering  process  must  occur  in  each  area,  to  select  a  design  that  optimally 
satisfies  the  requirements  and  objectives.  A  simple  block  diagram  of  the  EPS  is  shown  in 
Figure  15-42. 
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Figure  15-42:  EPS  Block  Diagram 

15.5.6.4  Power  Source 

The  power  source  generates  electrical  power  for  the  spacecraft,  supporting  the 
electrical  loads  over  many  orbits. 

15.5.6.4.1  System  Synthesis 

Spacecraft  typically  use  one  of  three  types  of  power  sources: 

1 .  Photovoltaic  solar  cells  are  the  most  common  power  source  for  Earth-orbiting 
spacecraft.  They  convert  incident  solar  energy  directly  to  electrical  energy  (McDermott, 
1992:392). 

2.  Static  power  sources  use  a  heat  source  for  direct  thermal-to-electric 
conversion.  Typical  sources  are  plutonium-238  or  a  uranium-235  nuclear  reactor 
(McDermott,  1992:392-393). 

-  The  thermoelectric  couple  uses  the  temperature  gradient  fi'om  the  slow  decay  of 
a  radioactive  source  to  provide  the  desired  dc  electrical  output  (McDermott,  1992:393). 
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-  Thermionic  energy  conversion  “produces  electricity  through  a  hot  electrode 
(emitter)  facing  a  cooler  electrode  (collector)  inside  a  sealed  container  that  typically 
contains  an  ionized  gas”  (McDermott,  1992:393).  Electrodes  evaporate  at  the  emitter, 
flow  across  the  gap,  condense  at  the  collector,  and  return  to  the  emitter  through  the 
electrical  load.  Thermionic  sources  usually  require  the  heat  temperature  of  a  nuclear 
reactor  source  (McDermott,  1992:394). 

3.  Dynamic  power  sources  “use  a  heat  source  and  a  heat  exchanger  to  drive  an 
engine  in  a  thermodynamic  power  cycle.  The  heat  source  can  be  concentrated  solar 
energy,  radioisotopes,  or  a  controlled  nuclear-fission  reaction.  Heat  from  the  source 
transfers  to  a  working  fluid,  which  drives  an  energy-conversion  heat  engine”  (McDermott, 
1992:394).  Radioisotopes  and  nuclear  reactors  provide  continuous  heat,  and  therefore  do 
not  require  energy  storage  for  eclipse  periods.  However,  dynamic  solar  power  sources 
retain  the  balance  of  energy  as  latent  heat  in  a  heat  exchanger.  This  provides  continuous 
energy  to  the  thermodynamic  cycle  during  eclipse  periods  (McDermott,  1992:394). 

The  most  common  of  these  sources  is  compared  in  Table  15-33. 
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Table  15-33:  Power  Source  Comparison 


EPS  Design 
Parameters 

Solar 

Photovoltaic 

Solar  Thermal 
Dynamic 

Radio¬ 

isotope 

Nuclear 

Reactor 

Power  range  (kW) 

0.2  -  25 

1-300 

0.2  -  10 

25  - 100 

Specific  power  (W/kg) 

26  - 100 

9-15 

8-10 

15-22 

Specific  cost  ($AV) 

Hardness 

2500  -  3000 

800  -1200 

16k  -  18k 

400  -  700 

-  Natural  radiation 

Medium 

High 

Very  high 

Very  high 

-  Nuclear  threat 

Medium 

High 

Very  high 

Very  high 

-  Laser  threat 

Medium 

High 

Very  high 

Very  high 

-  Pellets 

Low 

Medium 

Very  high 

Very  high 

Stability/maneuverability 

Low 

Medium 

Low 

Low 

Degradation  over  life 

Medium 

Medium 

Low 

Low 

Storage  required  for  solar 
eclipse 

Yes 

Yes 

No 

No 

Sensitivity  to  Sun  angle 

Medium 

High 

None 

None 

Sensitivity  to  spacecraft 
shadowing 

Low  (with  bypass 
diodes) 

High 

None 

None 

Obstruction  of  spacecraft 
viewing 

High 

High 

Low 

Medium  (due 
to  radiator) 

Fuel  availability 

Unlimited 

Unlimited 

Very  low 

Very  low 

Safety  analysis  reporting 

Minimal 

Minimal 

Routine 

Extensive 

IR  signature 

Low 

Medium 

Medium 

High 

Principal  applications 

Earth-orbiting 

spacecraft 

Interplanetary 

Interplanetary, 

Earth-orbiting 

spacecraft 

Interplanetary 

Source;  McDermott,  1992:393 


15.5.6.4.2  Tradeoffs  and  Decisions 

Solar  photovoltaics  are  the  typical  power  source  for  LEO  spacecraft.  They  are 
proven  and  widely  available.  Solar  power  is  adequate  for  the  intended  mission,  and  lighter 
(in  terms  of  specific  power)  than  the  other  alternatives.  Although  there  are  cheaper 
sources,  i.e.,  solar  thermal  dynamic  and  nuclear  reaction,  these  alternatives  require  more 
mass.  Nuclear  reactors,  furthermore,  require  a  fuel  that  has  limited  availability,  while  solar 
energy  is  unlimited.  Reactors  are  appropriate  for  applications  requiring  a  large  amount  of 
power,  but  not  for  the  loads  and  environment  expected  for  a  small,  tactical  LEO 
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spacecraft  such  as  Modsat.  The  same  can  be  said  of  the  solar  thermal  dynamic  alternative. 

The  radioisotope  alternative  fares  very  well  in  all  categories  shown  in  Table  15-33  but 

one,  wherein  it  is  very  cost  prohibitive.  Given  the  strong  emphasis  on  affordable  access  to 

LEO  missions,  the  radioisotope  alternative  was  ruled  out. 

Thus,  the  power  generation  system  of  choice  for  Modsat  is  photovoltaic  solar 

cells.  These  cells  must  be  mounted  on  solar  panels.  Solar  panels  can  either  be  planar  or 

cylindrical.  For  planar  panels,  the  “power  output  is  proportional  to  the  projection  of  their 

area  toward  the  incident  sunlight.  Three-axis-stabilized  spacecraft  normally  use  planar 

arrays”  (Reeves,  1992:3 17).  According  to  Reeves,  for  cylindrical  arrays, 

“the  output ...  is  nearly  proportional  to  the  amount  of  solar  energy 
intercepted,  and  the  projected  area  of  a  cylinder  is  \l%  times  the  total  area. 

Thus,  the  cylindrical  array  should  have  approximately  7t  times  as  many  cells 
as  a  planar  array  with  the  same  power  rating”  (Reeves,  1992:317). 

Since  Modsat  requires  a  great  deal  of  power  for  some  of  its  applications,  the  team 

decided  to  use  planar  arrays  as  opposed  to  cylindrical  arrays.  The  arrays  must  be  oriented 

toward  the  Sun  for  maximum  sunlight  incidence.  This  can  be  achieved  by  fixing  the  panels 

to  the  spacecraft  body  and  orienting  the  body  so  as  to  track  the  Sun  with  the  panels. 

However,  there  may  not  be  enough  available  area  on  the  body  of  the  spacecraft  for  body- 

mounted  arrays  to  provide  the  required  power,  and  thus  additional  panels  must  extend 

from  the  body.  Extended  arrays  on  deployable  booms  avoid  this  problem,  although  they 

add  appendages  to  the  spacecraft  which  add  to  the  mechanical  complexity  and  take  up 

precious  space  within  the  launch  vehicle  fairing.  Moreover,  it  is  easier  to  place  the  panels 

away  from  payload  instruments  and  other  temperature  sensitive  subsystems  which  could 

be  damaged  from  the  highly  variable  temperature  environment  of  solar  cells. 
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In  addition,  the  body-mounted  approach  uses  up  two  of  the  three  spacecraft  axes 
of  control  (see  section  15.1,3).  Recall  that  optical  mission  modules  must  be  nadir-pointed, 
which  also  requires  two  axes  of  control.  An  axis  of  control  can  be  freed  up  by  mounting 
the  planar  arrays  on  articulated  booms.  These  booms  must  work  in  conjunction  with  one 
of  the  spacecraft’s  control  axes  to  track  and  point  the  Sun  for  maximum  sunlight 
incidence. 

The  actual  mission  modules  for  each  Modsat  bus  are  not  known  at  this  stage. 
Power  requirements  can  vary  greatly  from  module  to  module,  and  it  is  unknown  where  the 
sensitive  instruments  will  be.  In  order  to  ensure  adequate  power  for  all  intended  missions, 
accommodate  a  wide  range  of  mission  module  design  and  spacecraft  subsystem 
arrangements,  and  facilitate  the  control  of  nadir-pointed  mission  equipment,  the  team 
decided  to  use  articulated  solar  arrays  on  deployable  booms. 

As  mentioned  earlier,  a  power  system  that  accommodates  the  highest-demand 
mission  modules  would  be  oversized  for  those  mission  modules  that  do  not  require  as 
much  power.  In  some  cases,  the  arrays  would  be  grossly  oversized.  It  is  desirable  to 
minimize  the  amount  of  excess  power  on  Modsat.  Moreover,  it  is  more  economical  to 
limit  the  size  of  the  solar  array  structure  to  the  size  necessary  to  produce  the  required 
power.  Therefore,  the  team  recommends  the  modular  solar  array  approach  used  by 
NASA’s  Small  Explorer  (SMEX)  Program  (Everett,  1996).  Modular  solar  array 
substrates  are  also  being  designed  by  Composite  Optics  for  possible  use  on  Phillips 
Laboratory’s  MightySat  II  spacecraft  (Hagan,  1996). 

In  the  modular  approach,  a  solar  array  is  constructed  of  smaller  solar  modules. 
These  modules  are  essentially  small  solar  panels  (8”  by  16”  for  the  SMEX  program). 
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which  can  be  purchased  in  mass  quantities  (at  reduced  prices)  long  before  assembly.  Once 
the  required  power  for  the  spacecraft  is  determined,  the  appropriate  number  of  modules 
can  be  pulled  from  storage  and  integrated  into  a  customized  solar  array  assembly.  This 
assembly  consists  mainly  of  a  structural  grid  for  inserting  the  solar  modules.  It  must  be 
built  so  as  to  conform  to  the  chosen  stowed/deployed  configurations  for  the  spacecraft. 
Modular  arrays  tend  to  have  a  slightly  lower  power  conversion  efficiency  compared  to 
traditional  arrays,  mainly  due  to  their  method  of  construction  and  integration  within  the 
grid.  But  this  inefficiency  is  made  up  for  by  the  reduced  cost  of  solar  array  expenditures 
and  engineering  (Everett,  1996). 

The  modular  approach  has  the  disadvantage  of  not  being  tailored  to  the  exact 
power  needs  of  the  spacecraft,  since  an  integer  number  of  solar  modules  must  be  used. 
However,  a  major  purpose  of  the  Modsat  concept  is  to  depart  from  the  customized 
approach  in  a  way  that  allows  flexibility  in  the  design  and  integration  of  each  spacecraft. 
Modular  solar  arrays  are  ideal  for  this  purpose.  Moreover,  the  traditional  approach  to 
designing  and  building  the  solar  arrays  typically  requires  much  advance  planning.  With  the 
modular  approach,  the  engineers  can  build  the  solar  array  assemblies  much  later  in  the 
overall  process  of  spacecraft  construction  (Everett,  1996). 

Although  the  modular  solar  array  approach  is  recommended,  the  team  decided  to 
design  each  of  the  alternative  Modsat  concepts  with  maximum  power  for  the  sake  of 
designing  to  the  most  difficult  set  of  requirements. 

In  section  15.5.3.5,  the  scheme  for  stowing  the  solar  arrays  during  launch  was 
discussed.  The  arrays  will  be  wrapped  around  the  bus  in  the  stowed  configuration.  Thus, 
the  amount  of  surface  area  provided  by  the  bus,  combined  with  the  number  of  wraps. 


272 


determines  the  power  generation  capability  of  the  arrays,  depending  on  the  efficiency  of 
the  solar  cells. 

A  study  was  conducted  on  three  major  types  of  cells:  silicon  (Si),  gallium  arsenide 
(GaAs),  and  indium  phosphide.  Performance  factors  are  shown  in  Table  15-34: 


Table  15-34:  Single-Cell  Performance  Comparison  for  Photovoltaic  Solar  Cells 


Cell  Type 

Silicon 

Gallium 

Arsenide 

Indium 

Phosphide 

Planar  cell  theoretical 

18% 

23% 

22% 

efficiency 

Achieved  efficiency 

14% 

18% 

19% 

Equivalent  time  in 
geosynchronous  orbit  for  1 5% 
degradation 

10  yr 

33  yr 

155  yr 

- 1  MeV  electrons 

2yr 

6  yr 

89  yr 

- 10  MeV  protons 

Source:  McDermott,  1992:397 


The  design  of  solar  arrays  involves  tradeoffs  between  mass,  area,  cost,  and  risk. 
Gallium  arsenide  and  indium  phosphide  provide  better  efficiency  and  longer  use  than 
silicon,  although  they  are  up  to  seven  times  more  expensive  in  terms  of  cost  per  watt. 
Indium  phosphide  is  a  relatively  immature  technology.  Given  the  desire  to  use  current, 
off-the-shelf  technology,  minimize  cost,  and  provide  a  design  lifetime  of  a  year,  indium 
phosphide  was  ruled  out.  Silicon  is  a  clear  choice  for  consideration.  It  is  a  proven, 
mature  technology  that  has  been  the  industry  standard  for  years,  although  it  is  more  bulky 
and  less  survivable  than  other  materials.  Gallium  arsenide  is  also  a  proven  technology,  and 
is  becoming  more  and  more  common  on  spacecraft.  Although  it  is  expensive  compared  to 
silicon,  alternatives  for  which  mass  and  volume  become  critical  may  require  the  use  of 
gallium  arsenide. 


273 


In  the  EPS  design  portion  of  the  Modsat  model  (see  Volume  III),  one  can  choose 
either  sihcon  or  gallium  arsenide  as  the  solar  cell  material.  However,  throughout  the 
design  process,  it  became  clear  that  silicon  cells  would  not  provide  enough  power  per  area 
to  satisfy  the  requirement  of  the  CDM  (up  to  500  watts),  given  the  stowed  configuration 
limitation  on  the  size  of  the  arrays.  Thus,  all  of  the  Modsat  alternatives  were  designed 
with  gaUium  arsenide  solar  cells. 

15.5.6.4.3  Design  Process 

The  following  process  was  used  to  design  and  size  the  solar  arrays  for  Modsat. 

1 .  Determine  the  following  factors: 

a.  Orbital  period 

b.  Maximum  eclipse  duration 

c.  Design  lifetime 

2.  Determine  the  available  solar  array  area. 

3.  Select  the  type  of  solar  cell  and  estimate  the  power  output,  with  the  Sun  normal  to  the 
surface  of  the  cells. 

4.  Determine  the  beginning-of-life  (BOL)  power  production  capability  per  unit  area  of  the 
array. 

5.  Determine  the  end-of-life  (EOL)  power  production  capability  per  unit  area  of  the  array. 

6.  Calculate  the  amount  of  raw  power  that  can  be  produced  by  the  arrays. 

7.  Calculate  the  amount  of  useful  power  that  can  be  produced  by  the  arrays. 

8.  Estimate  the  mass  of  the  solar  arrays. 
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Step  1:  The  orbital  period,  maximum  eclipse  duration,  and  the  period  of  the 
complementary  daylight  portion  of  the  orbit  must  be  calculated  for  the  baseline  orbit.  This 
is  performed  by  the  Modsat  model  (see  Volume  III).  The  design  lifetime  of  the  spacecraft 
must  be  chosen.  For  the  purposes  of  EPS  design,  a  lifetime  of  one  year  was  chosen  to  be 
consistent  with  the  requirements  of  the  CDM.  The  values  for  maximum  eclipse  duration 
and  design  lifetime  are  used  later  in  solar  array  calculations. 

Step  2:  The  available  solar  array  area,  Asa,  is  determined  through  structural  modeling. 

Step  3:  Once  the  type  of  solar  cell  has  been  chosen,  the  energy-conversion  efficiency  of 
the  cells  is  known.  From  this,  and  from  the  illumination  intensity  of  sunlight  at  normal 
incidence  (1358  WW),  the  power  output  capability  can  be  calculated.  This  power  output 
represents  the  ideal  capability  of  the  cells,  and  does  not  take  into  account  losses  and 
degradation  due  to  manufacturing  and  assembly,  known  as  inherent  degradation. 

The  achieved  energy-conversion  efficiencies  for  silicon  and  gallium  arsenide  are 
14%  and  18%,  respectively.  Thus,  the  power  output,  Po ,  can  be  calculated  as  follows 
(McDermott,  1992:395): 

Si:  Po  =  0.14  X  1358  W/m^=  190  WW  (Eqn  15-26) 

GaAs:  Po  =  0.18  x  1358  W/m^  =  244  W/m^  (Eqn  15-27) 

Step  4:  The  BOL  power  production  capability  per  unit  area  of  the  array  must  be 

determined  from  multiplying  the  ideal  power  output  by  factors  for  inherent  degradation 

and  non-normal  sunlight  incidence.  Inherent  degradation  is  contributed  to  by  three  basic 

elements,  as  shown  in  Table  15-35. 
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Table  15-35:  Inherent  Degradation 


Elements  of  Inherent  Degradation 

Nominal 

Range 

Design  and  assembly 

0.85 

0.77-0.90 

Temperature  of  array 

0.85 

0.80-0.98 

Shadowing  of  cells 

1.00 

0.80-1.00 

Inherent  Degradation 

0.77 

0.49-0.88 

Source:  McDermott,  1992:397 

The  factor  for  non-normal  sunlight  incidence  is  known  as  known  as  cosine  loss 
(McDermott,  1992:400).  This  can  be  determined  by  taking  the  cosine  of  the  worst-case 
sun  incidence  angle,  defined  between  the  vector  normal  to  the  surface  of  the  array  and  the 
Sun  line. 

BOL  power  production  per  unit  area,  Pbol,  is  (McDermott,  1992:400); 

Pbol  =  Po  Id  cosG  (Eqn  15-28) 

where  Id  is  the  inherent  degradation,  and  cos6  is  the  cosine  loss.  For  Modsat,  the  nominal 

value  of  Id,  and  the  worst-case  sun  angle  of  0  =  23.5  deg  (McDermott,  1992:400)  were 

used. 


Step  5:  EOL  power  production  capability  is  determined  by  multiplying  BOL 
power  production  per  unit  area  by  a  factor  for  lifetime  degradation.  This  degradation  is 
due  mainly  to  radiation  damage  from  the  space  environment.  Such  radiation  varies 
depending  on  the  orbital  altitude.  Other  factors  contributing  to  lifetime  degradation  are 
thermal  cycling,  micrometeoroid  strikes,  plume  impingement  fi-om  thrusters,  and  material 
outgassing  (McDermott,  1992:400). 
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In  general,  for  a  silicon  solar  array  in  LEO,  degradation  is  up  to  3.75%  per  year, 
while  for  gallium  arsenide  it  is  up  to  2.75%  per  year  (McDermott,  1992:400).  Cumulative 
degradation  depends  on  the  spacecraft  design  life. 

Lifetime  degradation,  La,  can  be  estimated  using  (McDermott,  1992:400): 

Z^=(l-/))^  (Eqn  15-29) 

where  D  is  the  degradation  per  year,  and  SL  is  the  spacecraft  design  life.  From  this, 

power  production  per  unit  area  at  EOL,  Peol,  is  (McDermott,  1992:401): 

Peol  ~  Pbol  Ld  (Eqn  15-30) 

Step  6:  The  raw  power  output  of  the  solar  arrays  at  EOL,  Praw,  is  determined  from 

(McDermott,  1992:401): 

Praw  Asa  Peol  (Eqn  15-31) 

Step  7:  Not  all  of  the  raw  power  is  available,  as  losses  occur  in  the  transmission  through 

wires,  batteries,  regulators,  and  converters.  Transmission  efficiencies  depend  on  the  type 

of  power  regulation  scheme  employed  by  the  spacecraft.  The  two  basic  types  of  schemes, 

discussed  in  section  15.5.6.7,  are  direct  energy  transfer  (DET)  and  peak-power  tracking 

(PPT).  DET  transmission  efficiencies  are  about  5%  to  7%  greater  than  PPT  transmission 

efficiencies  because  the  PPT  requires  a  power  converter  between  the  arrays  and  the  loads 

(McDermott,  1992:396). 

The  amount  of  useful  power  available  from  the  solar  arrays  at  EOL,  P,  can  be 
estimated  from  (McDermott,  1992:396) 

(Eqn  15-32) 

A  +  A 
A 
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where  Pe  and  Pa  are  the  spacecraft’s  average  power  requirements  (excluding  regulation 
and  battery  charging  losses)  during  eclipse  and  daylight,  respectively.  P^  and  Pa  were 
taken  to  be  equal  for  this  study.  Te  is  the  maximum  eclipse  period,  and  Ta  is  the  period  of 
the  complementary  daylight  portion  of  the  orbit.  The  terms  Xe  and  Xa  represent  the 
transmission  efficiency  of  the  paths  from  the  solar  arrays  through  the  batteries  to  the 
individual  loads  and  the  path  directly  from  the  arrays  to  the  loads,  respectively.  For  DET, 
the  efficiencies  can  be  estimated  at  Xe  =  0.65  and  Xa  =  0.85;  for  PPT  they  are  Xe  =0.60 
and  Xa  =  0.80  (McDermott,  1992:396). 

Step  8:  The  mass  of  the  solar  arrays  is  found  by  dividing  the  raw  power  output  of 
the  arrays  by  their  specific  performance.  The  specific  performance  range  of  current 
designs  is  14  to  47  W/kg  at  EOL  (Reeves,  1992:317). 

A  conservative  value  of  specific  performance,  25  W/kg,  was  chosen  to  calculate 
the  mass  of  the  solar  array,  Msa.  Thus, 

Msa  =  0.04  Psa  (Eqn  15-33) 

Example: 

1.  Let  Te  =  35  minutes;  Ta  =  53  minutes;  SL  =  1  year. 

2.  Let  Asa  =  7  m2 

3.  Choose  gallium  arsenide  solar  cells,  so  that  Po  =  244  watts/m2;  D  =  0.0275 

4.  Let  la  =  0.77;  0  =  23.5  deg;  thus,  Pbol  =  172  watts/m2 

5.  La  =  0.9725;  Peol  =167  watts/m2 

6.  Praw=  1169  watts 

7.  Design  for  a  DET  system;  thus,  Xe  =  0.65;  Xa  =  0.85;  =>  P  =  533  watts 
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A  final  consideration  for  the  solar  arrays  is  the  selection  of  solar  array  drive  motors 
(SADMs).  SADMs  are  necessary  to  mechanically  rotate  the  solar  array  structures  to 
achieve  optimum  angles  of  incidence  with  sunlight.  Two  SADMs  are  needed,  one  for 
each  solar  array.  For  modeling  purposes,  representative  SADMs  were  chosen  from  the  Jet 
Propulsion  Laboratory  (JPL)  Flight  Hardware  Survey,  with  the  following  characteristics: 

•  Mass:  5  kg  each. 

•  Dimensions:  Each  is  a  cylinder,  10  cm  diameter  by  27  cm  length. 

15.5.6.5  Energy  Storage 

15.5.6.5.1  System  Synthesis 

Since  Modsat  will  not  be  generating  power  with  a  constant  source,  such  as 
radioisotopes  or  nuclear  reaction,  a  system  must  be  designed  to  store  energy  for  eclipse 
operations.  The  storage  system  must  also  be  able  to  handle  peak  loads  beyond  the 
capability  of  the  solar  arrays,  which  are  designed  to  handle  average  loads. 

The  most  common  storage  devices  for  LEO  spacecraft  are  chemical  batteries, 
known  as  secondary  batteries  since  they  discharge  during  eclipse  and  recharge  in  sunlight 
(McDermott,  1992:402).  Other  storage  schemes  are  available,  such  as  thermal  storage, 
but  they  are  far  less  common  for  LEO  spacecraft  than  batteries.  Some  new  approaches, 
such  as  flywheel  storage,  require  much  less  weight  than  batteries.  However,  it  was 
decided  that  new  approaches  with  unproven  technology  would  not  be  appropriate  for  the 
Modsat  EPS.  Space  batteries  are  commonly  used  and  widely  available,  and  are  therefore 
appropriate  for  Modsat  energy  storage. 
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15.5.6.5.2  Tradeoffs  and  Decisions 

The  two  primary  types  of  batteries  in  use  today  are  nickel  cadmium  (NiCd)  and 
nickel  hydrogen  (NiH2)  batteries.  Specific  energy  density  ranges  for  these  battery  types 
are  shown  in  Table  15-36. 

Table  15-36;  Specific  Energy  Densities  of  Selected  Battery  Types 


Battery  Type 

Specific  Energy  Density  (W  hr/kg) 

Nickel  cadmium 

25-30 

Nickel  hydrogen  (individual  pressure  vessel 
design) 

25-40 

Nickel  hydrogen  (common  pressure  vessel 
design) 

45-60 

Source:  McDermott,  1992:403 

Nickel  cadmium  is  a  proven,  easily  available  and  comparatively  cheap  technology, 
but  it  delivers  a  relatively  low  energy  density.  Nickel  hydrogen  delivers  more  energy  per 
kilogram  than  nickel  cadmium,  but  it  is  more  expensive.  Moreover,  it  is  a  less  mature 
technology  for  LEO  applications  (McDermott,  1992:403).  However,  in  recent  years 
nickel  hydrogen  has  been  used  successfully  in  many  spacecraft.  The  new  common 
pressure  vessel  (CPV)  design  nickel  hydrogen  technology  was  successfully  qualified  on  the 
Clementine  mission  in  1994  (Clementine  Report). 

If  the  minimization  of  cost  was  the  highest-priority  objective  in  component 
selection,  nickel  cadmium  batteries  would  be  recommended  for  Modsat.  However,  the 
cost  objective  received  a  lower  priority  than  that  of  mission  utility.  In  addition,  since  the 
CDM  requested  a  peak  power  capability  of  1000  watts,  Modsat  requires  a  great  deal  of 
battery  capacity.  The  weight  of  the  bus  must  be  minimized;  therefore,  nickel  hydrogen 
was  preferred  by  the  team.  In  fact,  in  an  effort  to  drive  down  weight,  the  team  decided  to 

design  all  alternatives  with  two  nickel  hydrogen  CPV  batteries  fi'om  Johnson  Controls,  the 
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same  batteiy  flown  on  the  Clementine  mission.  Characteristics  of  this  battery  are  shown  in 
Table  15-37.  This  design  choice  gives  Modsat  30  amp-hours  of  battery  capacity. 


Table  15-37:  Characteristics  of  the  Johnson  Controls/CIementine  NiH2  CPV 

Battery 


#  of  cells 

Capacity 

Energy  density 

Dimensions  ’ 

(amp-hour) 

(W  hr/kg) 

(cm)  ( 

22 

15 

47.1 

50.8x13.4x13.4  - 

Source;  Clementine  Report 

It  should  be  noted  that  future  design  efforts  on  Modsat  could  result  in  the  selection 
of  different  batteries.  The  Modsat  model  allows  the  user  to  choose  from  a  list  of  batteries 


(see  Volume  III).  As  currently  designed,  the  Modsat  alternatives  do  not  offer  modularity 
in  the  power  storage  system.  The  NiH2  batteries  are  large  fixtures  within  the  spacecraft, 
and  would  be  very  difficult  to  remove  and  replace.  More  flexible  alternatives  were 
examined,  such  as  the  use  of  a  number  of  smaller  batteries  to  provide  the  same  capacity. 
Such  an  arrangement  would  potentially  allow  for  the  removal  of  unneeded  batteries  for 
less  demanding  applications.  For  instance,  the  SMEX  program  is  currently  designing 
spacecraft  busses  with  small  4  amp-hour  NiCd  battery  packs  (Everett,  1996).  SMEX 
engineers  are  able  to  select  the  number  of  required  batteries  for  a  given  mission. 

Although  such  modularity  would  provide  the  flexibility  sought  by  the  CDM,  it  has 
its  disadvantages.  A  modular  scheme  would  likely  employ  several  low-capacity  batteries. 
Research  into  currently  used  batteries  revealed  that  low-capacity  batteries  are  mostly 
available  in  the  NiCd  variety;  a  set  of  NiCd  batteries  could  weigh  twice  as  much  as  a  NiH2 
CPV  configuration,  for  the  same  capacity.  Moreover,  the  use  of  many  batteries  adds  to 
the  complexity  of  battery  charge/discharge  mechanics  and  control.  In  keeping  with  the 


importance  of  minimizing  weight  and  maximizing  capability,  the  team  traded  off 
modularity  for  a  low  weight,  high  power  battery  choice. 


15.5.6.5.3  Design  Process 

Spacecraft  bus  voltage  is  determined  by  the  voltage  of  the  batteries.  Typically, 
spacecraft  maintain  a  28  volt  bus,  from  which  power  is  converted  and  further  regulated  as 
needed  for  individual  loads.  The  voltage  of  a  battery  is  determined  by  the  number  of  cells 
in  series,  while  the  capacity  (watt-hrs  or  amp-hrs)  is  determined  by  the  number  of  cells  in 
parallel  (McDermott,  1992:401).  Thus,  batteries  can  be  connected  in  series  or  parallel  to 
provide  more  voltage  and  capacity,  respectively.  A  28-V  aerospace  battery  usually 
consists  of 22-23  series-connected  cells  (McDermott,  1992:403). 

The  orbit  of  the  spacecraft  determines  the  number  of  charge/discharge  cycles  the 
batteries  must  support  during  the  lifetime  of  the  spacecraft.  For  example,  a  LEO 
spacecraft  with  an  orbital  period  of  90  minutes  would  orbit  the  earth  5840  times  in  one 
year.  Since  an  eclipse  occurs  in  every  orbit  at  such  a  low  altitude,  the  batteries  would 
experience  5840  charge/discharge  cycles.  A  characteristic  of  secondary  batteries  is  that 
the  allowable  depth-of-discharge  (percentage  of  capacity  which  can  be  used  during  a 
cycle)  decreases  logarithmically  with  the  lifetime  number  of  charge/discharge  cycles,  as 
shown  in  Figure  15-43. 
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Source:  McDermott,  1992:404 

Figure  15-43:  Depth-of-Dischai^e  vs.  Cycle  Life  for  Batteries 

Once  the  number  of  cycles  and  average  DOD  are  known,  the  required  battery 

capacity  can  be  determined. 

The  EPS  engineer  must  ensure  that  the  batteries  can  provide  the  required  power 
during  every  eclipse.  The  highest  capacity  is  required  during  the  maximum  eclipse  period, 
Te.  This  capacity  is  calculated  as  PeTe,  where  Pe  is  the  required  average  eclipse  load. 

The  batteries  must  also  be  able  to  supplement  the  solar  arrays  in  the  provision  of  the  peak 
power  requirement.  The  corresponding  required  capacity  is  PpTp,  where  Pp  is  the 
difference  between  the  peak  load  requirement  and  the  average  power  supplied  by  the  solar 
arrays,  and  Tp  is  the  amount  of  time  during  which  peak  loads  are  required.  The  batteries 
should  be  sized  to  accommodate  the  largest  of  the  two  capacities  discussed  above. 

The  value  for  Tp  must  be  specified  as  a  requirement.  As  no  such  value  was 
specified  for  this  project,  the  team  decided  to  model  Modsat’s  peak  power  period 


283 


requirement  after  an  existing  program  of  a  similar  nature.  Phillips  Laboratory’s  MightySat 
program  is  developing  a  standardized  bus  for  space  experiments.  The  peak  power  period 
for  MightySat  is  specified  to  be  80%  of  the  average  daylight  period  (MightySat  TRD). 

The  team  adopted  this  requirement  for  Modsat,  with  the  exception  that  the  daylight  period 
used  is  Td,  the  complement  of  the  maximum  eclipse  period.  Thus,  for  Modsat,  Tp  =  0.8Td. 

The  capacity  requirement  for  the  batteries  is  the  ideal  capacity,  Ci,  that  the 
batteries  would  have  to  supply  if  there  were  no  battery-to-load  transmission  losses.  This 
must  be  increased  to  account  for  DOD  limitations  and  the  battery-to-load  transmission 
efficiency,  n.  For  this  study,  the  batteries  were  sized  based  on  a  transmission  efficiency  of 
90%.  If  the  chosen  number  of  batteries  is  N,  the  required  capacity  per  battery  is 
(McDermott,  1992:405) 


C  = 


C 


{DOD)Nn 


W~hr 


(Eqn  15-34) 


where  Ci  is  in  watt-hours.  The  corresponding  capacity  in  amp-hrs  is  determined  by 
dividing  the  W-hr  capacity  by  the  bus  voltage,  taken  to  be  28-V  for  this  study. 
Example: 


1 .  Let  Pe  =  500  W;  peak  load  =  1000  W;  T^  =  0.6  hr;  Tp  =  0.7  hr;  DOD  =  0.55;  N  =  1 

2.  Pp  =  500  W  Ci  =  350  W-hr 

3.  Cr  =  350/(0.55*0.9)  =  707  W-hr  =  25.25  amp-hr 

The  mass  of  the  batteries  is  found  by  dividing  the  total  storage  capacity  by  the 
specific  energy  density  (W-hr/kg)  of  the  type  of  battery. 
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15.5.6.6  Power  Distribution 


15.5.6.6.1  System  Synthesis 

The  power  distribution  system  consists  of  the  cabling,  fauh  protection,  and  power 
switching  gear  to  turn  power  on  and  off  to  the  spacecraft  loads.  A  major  focus  in 
distribution  system  design  is  on  keeping  mass  and  power  losses  at  a  minimum  while 
providing  survivability,  cost,  reliability,  and  power  quality. 

Distribution  systems  are  highly  unique  for  each  spacecraft,  since  each  has  its  own 
unique  arrangement  of  subsystems  and  mission  modules.  Thus,  the  load  profile  of  the 
spacecraft  must  be  known  in  order  to  design  an  efficient  distribution  system. 

However,  the  Modsat  concept  presents  a  unique  challenge  to  the  electrical 
engineer.  Since  it  is  intended  to  be  a  generic,  standardized  bus,  the  required  load  of  the 
mission  equipment  is  unknown  until  the  mission  need  arises.  Moreover,  flexibility  in 
configuration  is  a  key  value  of  the  decision  maker.  Therefore,  there  is  no  fixed  load 
profile  for  Modsat;  the  distribution  system  must  take  this  into  consideration. 

The  discussion  below  focuses  on  power  switching  and  distribution.  Power 
switches  may  either  be  standard  mechanical  relays,  or  solid-state  relays  based  on 
semiconductor  technology  (McDermott,  1992:405).  The  power  distribution  architecture 
may  be  centralized  or  decentralized,  depending  on  the  location  of  the  power  converters. 
The  centralized  approach  implies  a  regulated  bus,  with  a  unique  suite  of  converters  at  a 
central  location  that  distribute  converted,  regulated  power  to  known,  fixed  loads.  The 
decentralized  approach  implies  an  unregulated  bus,  with  conversion  and  regulation 
occurring  at  each  load  user  (McDermott,  1992:405)  . 


15.5.6.6.2  Tradeoffs  and  Decisions 

Mechanical  relays  are  the  clear  choice  “because  of  their  proven  flight  history, 
reliability,  and  low  power  dissipation”  (McDermott,  1992:405).  Solid-state  relays  may  be 
the  standard  choice  in  the  future,  but  presently  they  are  an  immature  space  technology. 
Since  minimizing  technological  risk  is  important  to  the  decision  maker,  solid-state  relays 
were  ruled  out. 

Decentralized  distribution  is  the  best  approach  for  Modsat.  It  allows  for  a  great 
deal  of  flexibility,  thereby  complementing  a  modular  architecture.  Each  power-using 
component,  including  the  mission  module,  must  provide  its  own  converter/regulator.  The 
load  nodes  will  be  fixed,  but  the  load  users  may  be  changed.  This  scheme  obviates  the 
need  for  customizing  the  distribution  network  for  each  mission  application. 

Another  consideration  for  power  distribution  is  battery  reconditioning.  Battery 
reconditioning  is  a  process  which  completely  drains  a  battery  in  order  to  eliminate  loss  of 
capacity  due  to  continuous  cycling  at  a  limited  depth-of-discharge.  It  requires  a  battery  to 
be  taken  completely  off-line,  drained,  and  recharged.  Battery  reconditioning  is  an  option 
for  the  designer  which,  if  chosen,  requires  extra  relays  and  shunt  resistors  to  bleed  the 
batteries  and  dissipate  their  energy.  Due  to  the  short  required  lifetime  of  Modsat,  battery 
reconditioning  has  not  been  considered. 

15.5.6.6.3  Design  Process 

The  distribution  system  should  include  provisions  for  fault  detection,  isolation,  and 
correction  during  testing  (McDermott,  1992:406).  Each  fully  integrated  Modsat 
spacecraft  must  undergo  extensive  testing,  especially  since  each  many  configurations  will 
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be  unique.  A  full  set  of  fuses,  placed  in  series  with  the  power  bus,  will  be  required  for 
fault  testing  (McDermott,  1992:407). 

The  mass  of  the  distribution  system,  excluding  wiring,  can  be  estimated  at  0.02  kg 
per  watt  of  distributed  power  (Reeves,  1992:319).  The  wiring  can  have  up  to  4%  of  the 
mass  of  the  dry  spacecraft  (Reeves,  1992:3 19).  Since  this  is  not  a  trivial  amount,  it  is 
important  to  keep  the  distribution  cables  as  short  as  possible. 

For  modeling  purposes,  a  power  control  unit  (PCU)  was  chosen  from  JPL’s  Flight 
Hardware  Survey  to  represent  the  distribution  system.  This  unit  is  a  24  x  16  x  20  cm  box. 

15.5.6.7  Power  Regulation  and  Control 
15.5.6.7.1  System  Synthesis 

Power  regulation  must  be  considered  for  three  key  elements:  controlling  the  solar 
array,  regulating  bus  voltage,  and  charging  the  battery  (McDermott,  1992:407).  Solar 
array  power  must  be  controlled  at  the  array  to  prevent  battery  overcharging  and  excessive 
spacecraft  heating  (McDermott,  1992:407).  Two  primary  schemes  are  available:  a  peak- 
power  tracker  (PPT)  and  a  direct-energy-transfer  (DET)  system  (McDermott,  1992:407; 
Everett,  1996).  A  PPT  is  nondissipative;  it  extracts  the  exact  amount  of  required  power 
up  to  the  array’s  peak  output.  A  PPT  operates  in  series  with  the  solar  array,  and  uses  4- 
7%  of  the  total  power  (McDermott,  1992:407).  The  DET  system  is  dissipative  because  it 
shunts  all  power  not  used  by  the  loads.  A  shunt  regulator  operates  in  parallel  to  the  array 
and  shunts  the  array  current  away  when  the  loads  or  battery  charging  do  not  require  the 
power  (McDermott,  1992:407). 
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Bus  voltage  may  be  unregulated,  quasi-regulated,  or  fully  regulated  (McDermott, 
1992:407).  In  an  unregulated  scheme,  bus  voltage  variation  equals  battery  voltage 
variation,  which  can  be  as  high  as  20%  between  charge  and  discharge  (McDermott, 
1992:407).  A  quasi-regulated  system  regulates  bus  voltage  during  battery  charge  but  not 
during  battery  discharge.  A  fully  regulated  system  employs  both  charge  and  discharge 
regulators. 

Batteries  can  be  charged  individually  or  in  parallel.  Parallel  charging  keeps  the 
voltage  of  all  batteries  the  same,  but  allows  current  and  temperature  to  vary  (McDermott, 
1992:409).  Individual  charging  “optimizes  the  battery  use  by  charging  all  the  batteries  to 
their  own  unique  limits”  (McDermott,  1992:409). 

15,5.6.7.2  Tradeoffs  and  Decisions 

A  DET  system  should  be  used  as  opposed  to  a  PPT.  The  DET  has  fewer  parts, 
lower  mass,  and  higher  total  efficiency  (McDermott,  1992:407).  These  qualities  are  highly 
desirable  within  the  Modsat  value  system.  It  is  unknown  exactly  how  much  power  will  be 
required  for  each  configuration  of  Modsat.  Thus,  it  seems  unlikely  that  one  PPT  could  be 
designed  for  all  applications.  Moreover,  given  the  use  of  modular  solar  arrays,  different 
Modsat  missions  will  have  different  amounts  of  power  being  supplied.  A  simple  shunt- 
regulated  system,  i.e.,  the  DET  system,  would  aid  in  the  integration  of  such  an 
architecture. 

For  reasons  discussed  in  section  15.5.6.6,  an  unregulated  system  should  be  used. 
Among  the  advantages  discussed  above  is  the  fact  that  more  regulation  involves 
dissipation  of  energy.  This  is  inefficient  and  could  potentially  create  heat  in  undesirable 
places. 
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Due  to  the  emphasis  on  design  flexibility,  it  seems  advantageous  to  employ 
independent  battery  chargers.  Their  use  aids  in  vehicle  integration  and  maximizes  the  use 
of  each  battery  (McDermott,  1992:409).  Future  iterations  of  the  Modsat  design  may 
adopt  a  modular  power  storage  approach,  in  a  scheme  where  a  battery  could  be  removed 
if  not  needed.  This  approach  is  greatly  facilitated  by  the  use  of  independent  charging,  and 
greatly  hampered  by  parallel  charging  (Everett,  1996).  On  the  other  hand,  independent 
charging  is  more  expensive  and  complicated  than  parallel  charging  (McDermott, 
1992:409),  and  adds  more  weight.  Although  the  choice  between  parallel  and  independent 
charging  may  not  be  an  issue  for  Modsat  concept  exploration,  the  current  tradeoff  of  cost 
for  mission  utility  led  the  team  to  recommend  the  independent  charging  approach. 

15.5.6.7.3  Design  Process 

An  example  of  an  unregulated  bus  using  a  shunt  regulator  and  an  independent 
charging  scheme  known  as  linear,  charge-current-control  (LC^),  is  diagrammed  in  Figure 
15-44.  (McDermott,  1992:409).  Note:  SA  =  solar  array;  SR  =  shunt  regulator. 


Source;  McDermott,  1992:408 

Figure  15-44:  Shunt  Regulator 
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The  mass  of  the  regulator  equipment  can  be  estimated  at  0.025  kg  per  watt  of 
regulated  power  (Reeves,  1992:319). 

For  modeling  purposes,  a  shunt  regulator  was  chosen  from  JPL’s  Flight  Hardware 
Survey  to  represent  the  regulation  system.  This  unit  is  a  42  x  18  x  1 1  cm  box. 

15.5.6.8  Future  Effort 

The  Modsat  EPS  must  be  integrated  into  the  whole  Modsat  bus  in  an  intelligent 
manner.  Further  design  effort  for  Modsat  must  take  these  elements  into  consideration: 

•  Electrical  loads  must  be  supplied  to  the  mission  module  and  to  the  other  components 
in  the  bus. 

•  EPS  must  have  a  command  and  telemetry  interface.  Designers  must  eventually 
determine  which  EPS  components  require  commanding,  and  which  must  report  health 
and  status.  An  appropriate  collection  node  must  be  integrated  into  the  command  and 
data  handling  architecture  of  Modsat. 

•  Each  component  has  an  operating  temperature  range.  All  components  must  be 
physically  arranged  and  thermally  controlled  to  maintain  an  adequate  thermal 
environment  for  the  spacecraft.  Some  typical  operating  ranges  are  listed  in  Table  15- 
38. 

•  EPS  components  radiate  heat,  as  energy  is  dissipated  through  transmission,  regulation, 
etc.  The  components  must  be  located  so  that  this  heat  does  not  negatively  affect  other 
sensitive  spacecraft  components.  For  instance,  the  shunt  regulator  for  the  solar  arrays 
could  dissipate  large  amounts  of  unneeded  energy.  It  is  necessary  to  radiate  this  heat 
directly  into  space,  away  from  the  spacecraft,  wherever  possible. 
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•  The  spacecraft  will  have  various  power  switching  requirements,  both  routine  and  for 
redundancy  purposes.  The  EPS  must  incorporate  the  appropriate  equipment  to  handle 
this  function. 

•  The  spacecraft  operating  system  must  manage  EPS  operations.  For  example,  there 
must  be  a  way  to  control  the  use  of  the  batteries  when  they  are  needed.  Another 
example  is  the  process  of  load  shedding  during  an  emergency,  whereby  power  is 
turned  off  to  selected  subsystems  in  an  effort  to  conserve  power. 


Table  15-38:  Operating  Temperature  Range 


Components 

Typical  Temperature  Range,  °C 

Electronics 

0  to  40 

Batteries 

5  to  20 

Solar  Arrays 

-100  to +100 

Source;  McMordie,  1995:410 


As  various  spacecraft  power  technologies  become  qualified  and  proven  over  the 
next  few  years,  their  use  within  Modsat  should  be  examined.  It  is  likely  that  industry  will 
develop  some  attractive  alternatives  to  the  traditional  menu  (i.e.,  light-weight  flywheels  for 
energy  storage).  Such  technologies  may  be  well  suited  to  the  standardized  bus  approach. 

15.6  Tradeoff  Summary 


15.6.1  System  Level 

•  One  satellite  per  launch  vehicle 

•  3 -axis  stabilization 

•  Modular  component  interfaces 

•  On-board  propulsion 
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•  Mission  data  storage 

•  Spacecraft  to  Payload  Interface  Guideline  (SPIG)  interface 
15.6.2  Subsystem  Level 

ATTITUDE  DETERMINATION  AND  CONTROL 

•  Inertial  Measurement  Unit 

•  Star  sensor 

•  Earth  sensor 

•  Reaction  wheels 
PROPULSION 

•  Monopropellant  configuration 

•  Hydrazine  blend  propellant;  24%  HN,  76%  N2H4 

•  Blowdown  pressure  system 

•  Positive  expulsion  fuel  storage  system 

•  Bottom  level  location  for  the  system 

•  cylindrical  tanks 

•  thrusters 
STRUCTURES 

•  Octagon  “cage”  structures  with  “polysat”  design 

•  Modular  mounting  plates 
THERMAL 

•  Interface  thermal  blanket  between  the  mission  module  and  satellite  bus 
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TTC/CDH 


•  Satellite  Operating  System 

»  software  handles  interrupt  requests  to  collect  telemetry  and  handle  housekeeping 

•  Internet  communication  format  (TCP/EP) 

»  JAVA  compatible  architecture  enables  user  in  field  to  access  data  via  browser 
capable  system 

»  provides  point-and-click  environment  to  control  satellite 
»  encryption  on  demand  with  software  plug-in  modules 
EPS 

•  Modular  solar  arrays  on  deployable,  articulated  booms 

•  Solar  arrays  wrap  around  the  bus  in  the  stowed  launch  configuration 

•  Gallium  arsenide  solar  cells 

•  NiH2  common  pressure  vessel  batteries 

•  Decentralized,  unregulated  distribution 

•  Shunt  regulation;  individual  battery  charging 
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16.  Modeling 


Modeling  plays  an  important  role  in  solving  complex  and  multiple  variable 
problems;  as  such,  it  is  a  critical  element  of  systems  engineering.  Upon  using  systems 
engineering  to  design  a  standardized  tactical  satellite  bus,  the  team  was  faced  with  many 
variables  and  the  relationships  between  them.  Satellite  design  by  its  very  nature  is  quite 
complicated,  and  trying  to  account  for  every  detail  in  a  preliminary  study  is  infeasible. 
Modeling  enabled  the  team  to  approach  the  design  at  a  high  level,  focusing  only  on  the 
major  elements  of  the  spacecraft.  The  team  also  used  the  model  to  evaluate  the 
performance  of  the  alternative  solutions. 

Before  considering  modeling  methods,  it  was  important  to  focus  on  the  problem 
definition,  objectives,  and  measures  of  effectiveness  (MOEs).  This  ensures  that  the  model 
is  fully  relevant  to  the  problem.  The  model  must  be  able  to  evaluate  the  alternatives 
proposed  to  solve  the  problem,  within  the  framework  established  for  that  evaluation. 

Once  the  basis  for  the  Modsat  model  was  understood,  the  team  outlined  the  scope 
and  type  of  model  necessary  to  meet  the  objectives.  Starting  from  a  high  level,  the  team 
determined  that  the  Modsat  model  must  be  highly  integrated  (able  to  perform  both  design 
and  evaluation)  and  adaptable.  The  various  elements  of  the  model  (i.e.,  subsystem  design 
modules)  must  be  compatible  with  the  overall  model  and  with  each  other.  The  “integrated 
and  compatible”  requirement  ensures  that  all  of  the  subsystem  designs  created  in  the 
model  can  be  brought  together  and  combined  into  a  proposed  satellite  design  for  further 
analysis.  “Adaptability”  means  the  satellite  designer  can  easily  modify  and/or  expand  the 
model  to  change  its  analysis  and  design  characteristics. 
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In  searching  for  an  integrated  model,  the  team  queried  the  Internet  and 
investigated  software  maintained  by  AFIT,  without  success.  Therefore,  to  fulfill  the 
integrated  model  requirement,  the  team  turned  to  Matlab,  a  mathematical  and  graphics 
software  package,  to  develop  an  in-house  satellite  design  model. 

In  addition  to  integrating  all  the  various  subsystems,  the  model  must  test  the 
integrated  satellite  designs  to  ensure  they  meet  launch  and  on-orbit  operational 
requirements.  It  must  also  determine  how  well  the  proposed  alternative  meets  the  criteria 
established  in  the  value  system. 

In  creating  the  model  to  meet  all  these  requirements,  the  team  started  with  a  high- 
level  structure  as  shown  in  Figure  16-1. 


Build  satellite  components  and 
create  a  satellite  database 


Check  for  subsystem  overlap 
Check  weight  dimensions  against 
launch  vehicle  constraints 
Calculate  key  satellite 


Check  for  subsystem  interoperability 


Subject  the  satellite  to  various  test 


Take  test  results  and  report  how  well 
the  satellite  met  the  MOEs 


Figure  16-1:  Logical  Flow  of  Modsat  Model 
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The  Modsat  model  is  geared  toward  sequential  operation,  starting  from  the  top  of 
the  logic  flow  diagram  and  working  down.  Building  satellite  components  and  bringing 
them  together  in  one  integrated  satellite  database  is  the  first  step.  Next,  Modsat  checks 
the  satellite  database  to  ensure  total  satellite  mass,  center  of  mass,  and  sizing  meet  the 
launch  vehicle  constraints.  Once  the  satellite  database  passes  these  physical  constraints,  it 
must  also  pass  operating  requirements.  In  this  same  step  cost  and  reliability  are 
determined.  At  this  point  the  satellite  is  integrated,  and  the  subcomponents  will  physically 
fit  together  within  the  launch  vehicle,  but  it  is  not  known  how  well  the  satellite  will 
perform  in  the  space  environment,  Therefore,  the  satellite  bus  must  be  subjected  to  launch 
and  orbit  tests  to  determine  how  well  this  particular  satellite  configuration  will  do.  These 
results  are  fed  into  data  analysis  to  be  evaluated  against  the  objectives.  Each  design 
receives  an  overall  utility  score,  and  the  designs  are  ranked  from  highest  to  lowest. 

Finally,  sensitivity  analysis  is  performed  by  varying  the  top  level  objective  weights.  This 
shows  how  well  a  design  will  do  when  subjected  to  changing  environments. 

Although  the  Modsat  model  uses  first  order  assumptions  and  calculations,  it 
proved  to  be  an  excellent  systems  engineering  tool.  For  a  full  description  of  the  model, 
see  Volume  HI. 
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17.  System  Synthesis 


The  first  iteration  of  System  Synthesis  concentrated  on  large-scale  architectures  as 
opposed  to  individual  satellite  designs.  These  architectures  philosophically  captured  the 
different  approaches  to  constellation  employment  available  to  the  designer  of  a  standard 
satellite  concept  capable  of  supporting  multiple  tactical  users  and  their  requirements. 
Further  satellite  design  research  refocused  the  system  design  effort  to  a  narrower,  more 
detailed  scope.  This  focused  approach  concentrated  on  the  goal  of  generating  the  best 
design  for  a  single,  standard  spacecraft  bus.  As  the  large-scale  architectural  concepts  do 
not  preclude  the  use  of  standardized  components  amongst  them,  the  “baseline”  or  “one 
size  fits  all”  architecture  became  the  focus  of  design  efforts. 

The  original  architectural  themes  presented  early  in  the  system  design  process  lend 
themselves  to  serve  as  implementation  schemes  applicable  to  the  standard  design  (i.e., 
“evolving”  the  baseline  bus  design).  With  a  standard  design  in  hand,  application  of 
architectural  themes  to  this  design  may  further  enhance  that  design’s  ability  to  support 
specific  mission  modules  (if  not  also  improve  its  overall  performance). 


17.1  Subsystem  Baselines 

Taken  as  a  whole,  the  design  options  available  for  the  design  of  spacecraft  buses 
are  myriad.  The  classical  morphological  system  synthesis  methodology  is  too  cumbersome 
to  be  used  in  this  case,  given  the  design  objectives  of  bus  standardization,  tactical 
responsiveness,  and  adaptable  application  (not  to  mention  the  time  fi-ame  in  which  the 
system  process  was  applied).  The  design  philosophy  adopted  for  the  generation  of 
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candidate  spacecraft  bus  designs  begins  with  the  tradeoff  studies  presented  by  each  of  the 
designated  subsystem  experts.  These  tradeoff  studies  at  each  subsystem  level  served  to 
narrow  the  candidate  design  solution  space,  focusing  on  design  points  which,  when 
applied  to  different  designs,  would  exhibit  the  greatest  variances  in  utility  or  represent  the 
greatest  differences  in  approaches  to  certain  bus  capabilities. 

Each  subsystem  level  study  addressed  the  selection  of  individual  subcomponents 
and  the  narrowing  of  requirements  for  each  satellite  subsystem.  Most  of  these  choices 
then  became  fixed  in  all  of  the  candidate  designs.  Each  design  would  then  yield  a  baseline 
design  from  which  alternative  configurations  could  be  based,  by  varying  the  characteristics 
and/or  configurations  of  the  subsystems  not  fully  determined  by  the  trade  studies.  This 
streamlined  approach  to  subsystem  and  eventual  system  design  facilitated  the  focusing  of 
the  effort  and  the  effective  utilization  of  extensive  satellite  subsystem  expertise  by  the 
more  experienced  team  members. 


17.2  Alternative  Design  Descriptions 

The  following  discussion  details  the  alternative  designs  evaluated  using  the  Modsat 
computer  modeling,  design,  and  analysis  software.  To  begin  scoping  the  alternatives,  all 
were  designed  to  be  compatible  with  the  Pegasus  XL/without  HAPS  configuration.  Of 
the  seven  designs,  six  are  based  on  the  38”  interface,  while  the  seventh  is  based  on  the  23” 
interface.  The  team  judged  early  in  the  design  process  that  the  23”  interface  configuration 
probably  would  not  provide  enough  volume  for  Modsat  because  it  reduces  volume  for  the 
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mission  module  and  the  size  of  the  solar  arrays.  However,  one  alternative  with  this 
interface  was  generated  for  the  sake  of  a  complete  analysis. 

The  designs  fall  into  one  of  two  categories.  In  the  first  category,  there  are  three 
levels  for  component  placement.  The  third  level  has  a  Supplemental  Mission  Adaptive 
Shelf,  or  “SMASH”,  which  is  a  large  volume  of  space  reserved  for  either  a  dedicated  high 
data  rate  antenna  and  its  transponder,  or  some  other  user-specified  payload  or  mission- 
unique  equipment.  The  second  category  has  only  two  levels,  reducing  the  overall  bus 
height  by  not  including  a  SMASH  for  additional  mission  equipment  (such  as  a  high  data 
rate  communications  package).  In  the  case  of  the  second  category  designs,  all  mission- 
unique  equipment  would  be  placed  entirely  on  the  payload  interface  plate  (very  top  of  the 
bus). 

All  designs  fit  a  particular  tactical  profile,  with  tactical  capability  being  determined 
by  the  amount  of  fuel  on-board.  Those  designs  with  more  fiiel  have  more  ability  to  make 
in  plane  or  out  of  plane  maneuvers,  satellite  altitude  corrections,  or  other  maneuvers.  In¬ 
plane  changes  can  be  measured  by  AV;  thus,  total  AV  capability  is  the  measure  for  how 
much  a  satellite  can  change  its  velocity.  AV  capability  is  directly  proportional  to  the 
amount  of  fuel  carried  by  the  spacecraft.  All  of  the  designs  have  varying  amounts  of  AV 
capability  according  to  three  sizes  of  propellant  tanks  carried  by  the  spacecraft.  There  are 
three  profiles  for  AV:  max  (450  m/s),  mid  (300  m/s),  and  low  (100  m/s).  These  tactical 
profiles  correspond  to  varying  demands  which  may  or  may  not  be  placed  on  the  satellite 
during  its  mission.  For  a  given  category  the  three  tactical  profiles  are  essentially  the  same 
except  for  the  size  of  the  propellant  tanks.  Since  the  bottom  level  of  the  bus  is  reserved 
for  propulsion,  different  tank  sizes  will  raise  or  lower  the  bottom  mounting  plate,  thus 
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increasing/decreasing  the  overall  height  of  the  satellite  bus.  The  three  tactical  profiles  and 
their  capabilities  are  summarized  in  Table  17-39; 


Table  17-39;  Tactical  profiles 


MAX 

Maximum  AV  capacity  for  orbit  maintenance 

Up  to  2.5  degrees  of  inclination  change  during  mission 

MID 

Medium  AV  capacity  for  orbit  maintenance 

Up  to  1.5  degrees  of  inclination  change  during  mission 

LOW 

Minimum  AV  capacity  for  orbit  maintenance  (one  year) 

All  designs  have  the  same  power  supply  capability  (447  Watts  average/1000  Watts 
peak),  except  for  the  23”  interface  design,  which  has  lower  output  (390  Watts  avg,  950 
Watts  peak)  due  to  reduced  solar  array  area.  The  seven  designs  generated  as  alternative 
solutions  are  as  follows; 

•  MAXTAC;  Max  tactical  profile,  with  three  component  levels  and  SMASH 

•  MEDTAC;  Mid  tactical  profile,  with  three  component  levels  and  SMASH 

•  LOWTAC;  Low  tactical  profile,  with  three  component  levels  and  SMASH 

•  MAXTAC-N;  Max  tactical  profile,  with  two  component  levels  and  no  SMASH 

•  MIDTAC-N;  Mid  tactical  profile,  with  two  component  levels  and  no  SMASH 

•  LOWTAC-N;  Low  tactical  profile,  with  two  component  levels  and  no  SMASH 

•  MIDT AC-23;  Mid  tactical  profile,  with  three  component  levels  and  SMASH;  23  inch 
interface 

The  major  characteristics  of  each  design,  including  the  height  of  each  bus,  were 
determined  through  modeling,  and  the  results  are  shown  in  Table  17-40. 
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Table  17-40:  Major  Design  Characteristics 


Acronym 

SMASH 

Number  of 
Levels 

AV 

(m/s) 

Interface 

(in) 

Bus  Height 
(cm) 

MAXTAC 

Yes 

3 

38” 

71 

MIDTAC 

Yes 

3 

38” 

68 

LOWTAC 

Yes 

3 

38” 

63 

MAXTAC-N 

No 

2 

450 

38” 

69 

MIDTAC-N 

No 

2 

300 

38” 

66 

LOWTAC-N 

No 

2 

100 

38” 

61 

MIDTAC-23 

Yes 

3 

300 

23” 

95.7 

17.3  Convergence  of  Individual  Designs 

The  system  trades,  subsystem  trades,  and  the  category/tactical  profile  options 
together  form  the  basis  for  a  set  of  feasible,  alternative  satellite  designs.  Based  on  the 
research  done  at  the  subsystem  level,  the  team  was  able  to  develop  a  high-level  set  of 
required  components  and  characteristics  for  Modsat  (see  section  17.4).  However,  an 
actual  satellite  design  is  an  integrated  system,  and  not  simply  a  collection  of  components 
individually  meeting  requirements.  The  overall  integrated  satellite  design  and  concepts 
must  meet  the  requirements  for  this  design  study.  In  order  to  effectively  evaluate  the 
alternatives,  they  must  each  form  a  complete  satellite  design,  wherein  components  are 
properly  positioned  within  the  structure  of  the  satellite. 

Although  the  Modsat  designs  are  very  similar,  they  differ  by  category,  tactical 
profile,  and  launch  configuration.  The  team  developed  a  “baseline”  Modsat  design  by 
determining  the  optimal  placement  of  subcomponents.  From  this  “baseline”  design,  other 
designs  were  created  by  simply  varying  the  satellite  configuration  to  accommodate  the 
various  category  (SMASH/no  SMASH)  and  tactical  profile  (propulsion)  options.  The 
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design  most  divergent  from  the  rest,  of  course,  is  the  design  based  upon  the  Pegasus  23- 
inch  interface. 

The  process  of  satellite  design  convergence  began  with  the  Pegasus  payload  bay 
size,  weight,  and  center  of  gravity  constraints.  While  the  structure  was  being  developed  to 
fit  within  the  payload  bay,  the  major  design  effort  focused  on  the  problem  of  intelligently 
fitting  and  integrating  the  subcomponents  within  it  while  maximizing  the  remaining  volume 
for  the  mission  module.  The  main  size  constraint  is  the  payload  bay’s  diameter  and  overall 
height,  since  the  mission  module/satellite  bus  must  physically  fit  within  the  LV  fairing 
shown  below  in  Figure  17-1. 


Payload 


Payload 

Figure  17-1:  Typical  Launch  Vehicle  Shroud  Configuration 

Starting  with  the  interface  plate  of  the  launch  vehicle  and  proceeding  upwards  with 

successive  component  “mounting  plates,”  the  placement  of  components  was  initially 
estimated,  spatially  evaluated,  and  iteratively  adjusted,  until  a  reasonable,  desirable 
arrangement  of  components  solidified  into  an  integrated  satelhte  design.  The  semi- 
cylindrical,  shelf-like  structure  chosen  for  Modsat  is  conducive  to  this  design  convergence 
approach  and  facihtates  the  organization  of  components  into  “functional”  groups. 
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It  should  be  noted  that  the  particular  component  placement  schemes  chosen  by  the 
team  are  not  intended  to  be  set  in  stone.  The  team  used  common  sense  to  arrange  the 
equipment  within  the  bus,  though  no  member  of  the  team  had  any  prior  experience 
designing  spacecraft.  Future  iterations  on  the  design  of  Modsat  may  very  well  yield 
altered  component  arrangements.  Moreover,  only  those  major  components  analyzed  in 
this  study  were  placed  in  the  bus.  A  more  detailed  design  effort  must  include  a  more 
complete  set  of  spacecraft  hardware. 


17.4  Component/Characteristic  Listing 

The  following  list  summarizes  the  set  of  characteristics  and  components  that  were 
chosen  for  Modsat.  It  should  be  clear  that,  to  be  consistent  with  the  scope  of  this  study, 
this  is  a  high-level  set  of  major  components.  The  rationale  behind  the  selection  of  these 
components  is  discussed  in  the  Tradeoffs  section  of  this  report.  Only  those  characteristics 
that  were  relevant  to  the  integration  of  the  overall  design  are  included  below. 

•  Launch  Vehicle  Fairing  Static  Envelope  (inside  of  which  the  spacecraft  may  be  placed) 
Note:  The  Pegasus  User ’s  Guide  specifies  a  dynamic  envelope  of  46  The  team 
decided  to  use  a  more  conservative  static  envelope  due  to  the  risk  inherent  in  the  use 
of  the  wrap-around  solar  array  assemblies.  This  approach  is  used  by  the  SMEX 
program  (Everett,  1996). 

•  Diameter;  44”  «  1 12  cm 

•  Height  from  spacecraft  interface  to  curve  in  fairing:  1 1 1  cm 

•  Structures  and  Mechanisms 

Note:  All  structural  members  are  made  of  7075-T6  aluminum,  with  a  density  of 
2,800  kg/m^. 

•  Shape:  Octagon 
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•  Structural  cylindrical  columns  (8) 

-  Dimensions:  hollow;  4  cm  outer  diameter;  1.5  cm  inner  diameter;  height 
varies  with  each  design 

•  LV  interface  plate 

-  Diameter;  1 1 1 . 76  cm 

-  Thickness:  1  cm 

•  Component  mounting  plates  (2  for  with  SMASH,  1  for  no  SMASH;  note  that 
the  LV  interface  plate  forms  the  bottom  component  plate) 

-  Diameter:  87.26  cm 

-  Thickness:  0.2  cm 

•  Center  spine 

-  Dimensions;  5  cm  square;  hollow;  height  varies  with  each  design 

•  Propulsion 

•  Propellant  tanks  (4) 

-  Dimensions:  hollow  cylinder;  2  tanks  are  42  cm  long,  2  are  33  cm  long; 
diameter  varies  with  tactical  profile 

•  Thrusters  (6) 

-  Dimensions:  modeled  as  a  cylinder;  6.6  cm  diameter;  10.2  cm  height 

•  Valves  (6) 

-  Dimensions;  modeled  as  a  cylinder;  6.6  cm  diameter;  8.2  cm  height 

•  ADCS 

•  Reaction  wheels  (4) 

-  Dimensions:  cylinder;  25.5  cm  diameter;  9  cm  height 

-  Mass:  5.1  kg  each 

-  Power  requirement:  17  watts  max 

•  Reaction  wheel  electronics  boxes  (4) 

-  Dimensions:  box;  17.8  by  15.2  by  3.2  cm 

-  Mass;  0.9  kg  each 

•  Earth  sensor  (head) 

-  Dimensions;  cylinder;  10.4  cm  diameter;  16.3  cm  length 

-  Mass;  1.27  kg 

-  Power  requirement:  0.5  watts 


304 


•  Earth  sensor  (electronics) 

-  Dimensions;  box;  10.2  by  20.3  by  6.7  cm 

-  Mass:  1.14  kg 

-  Power  requirement;  3.5  watts 

•  Star  sensor 

-  Dimensions:  cylinder;  13.5  cm  diameter;  14.2  cm  length 

-  Mass:  2.5  kg 

-  Power  requirement:  10  watts 

•  Inertial  Measurement  Unit  (IMU) 

-  Dimensions;  cylinder;  21.6  cm  diameter;  13.3  cm  height 

-  Mass:  3.72  kg 

-  Power  requirement:  33  watts 

•  EPS 

•  Solar  array  panels  (16) 

Note:  Since  the  bus  has  an  octagon  shape,  there  are  eight  hinged  panels  per 
wrap  around  the  bus.  All  configurations  used  two  wraps,  therefore  all  have 
16  panels. 

-  Dimensions:  box 

—  Thickness;  4  cm 

—  Width:  inner  wrap  panels  are  36. 14  cm  wide;  outer  wrap  panels  are 
39.45  cm  wide 

—  Height:  varies  with  each  design 

-  Mass:  varies  with  size  of  arrays 

•  Batteries  (2  NiH2) 

-  Dimensions:  cylinder;  13.4  cm  diameter;  50.8  cm  length 

-  Mass;  9.5  each 

-  Capacity:  15  amp-hours  each 

•  Regulator 

-  Dimensions:  box;  42  by  18  by  11  cm 

-  Mass:  varies  with  power  output 

•  Power  Control  Unit  (PCU) 

-  Dimensions:  box;  24  by  16  by  20 

-  Mass:  varies  with  power  output 

•  Solar  Array  Drive  Motors  (2  SADMs) 

-  Dimensions:  cylinder;  10  cm  diameter;  27  cm  length 

-  Mass:  5  kg  each 
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•  TT&C/CDH 


•  Transceiver 

-  Dimensions:  box;  21  by  15  by  13  cm 

-  Mass:  3.41  kg 

-  Power  requirement:  22  watts 

•  SGLS  Antennas  (2) 

-  Dimensions:  cylinder;  4  cm  diameter;  10.2  cm  height 

-  Mass:  0.25  kg  each 

•  Central  Processing  Unit  (CPU) 

-  Dimensions:  box;  5  by  22  by  15 

-  Mass:  0.9  kg 

-  Power  requirement:  2.8  watts 

•  Data  Storage  Unit 

-  Dimensions:  box;  13  by  13  by  13 

-  Mass:  3.4  kg 

-  Power  requirement:  1  watt 


17.5  Baseline  Design 

The  MAXTAC  bus  (maximum  propulsion,  three  shelves  with  SMASH)  was 
chosen  as  the  baseline  upon  which  to  conduct  the  detailed  placement  of  components.  The 
following  discussion  applies  to  the  design  of  the  MAXTAC.  In  section  17.6,  the  other 
alternatives  will  be  discussed.  The  complete  set  of  databases  for  each  design  is  included 
with  the  modeling  software  (see  Volume  HI). 

With  the  basic  structure  at  hand,  the  team  had  to  choose  desired  locations  for  the 
components.  It  was  decided  to  place  the  components  as  shown  in  Table  17-41. 
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Table  17-41:  Component  Placement 


Component  Level 

Components 

1st 

Propulsion;  one  SGLS  antenna 

2nd 

Batteries;  PCU;  Regulator;  Reaction  wheels 
and  electronics;  Earth  sensor  and  electronics; 

Star  sensor 

3rd 

IMU;  TTC  &  CPU  components;  SADMs 

The  rationale  for  locating  the  propulsion  subsystem  on  the  bottom  level  is 
documented  in  the  Tradeoffs  section  of  this  report.  It  was  decided  to  place  a  SGLS 
antenna  on  the  bottom  level  as  well,  such  that  the  antenna  would  have  a  field  of  view 
through  a  hole  in  the  LV  interface  plate.  It  was  felt  that  an  antenna  was  necessary  in  this 
location  in  order  to  communicate  with  Modsat  prior  to  its  full  structural  deployment! 

The  team  decided  to  place  components  on  the  second  level  in  such  a  way  as  to 
keep  the  spacecraft  center  of  mass  as  low  as  possible  (due  to  LV  considerations).  Thus, 
the  relatively  massive  batteries  and  reaction  wheels  were  placed  on  the  second  level.  In 
order  to  collocate  as  many  subsystem  components  as  possible,  the  regulator,  CPU, 
reaction  wheel  electronics,  earth  sensor  and  electronics,  and  star  sensor  were  placed  on 
the  second  level  as  well. 

However,  it  was  necessary  to  place  the  SADMs  on  the  third  level.  The  axis  of  the 
SADMs  must  be  aligned  with  the  axis  of  the  solar  array  assemblies,  which  must  in  turn  be 
located  high  enough  to  provide  a  balanced  inertia  matrix  for  the  total  spacecraft.  In 
addition,  the  SADMs  must  be  placed  on  the  outer  edge  of  the  component  plate,  in  order 
to  mate  with  the  extended  solar  array  booms.  The  remaining  TT&C/CPU  components 
were  placed  on  the  third  level.  Nearly  one  half  of  the  third  level  was  reserved  for  the 
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SMASH.  The  team  modeled  the  use  of  this  space  with  a  hypothetical  high  data  rate 
(HDR)  package,  consisting  of  an  antenna  and  a  transceiver.  The  antenna  was  modeled  as 
a  large  cylinder,  while  the  transceiver  was  chosen  to  be  identical  to  the  TT&C  transceiver. 

The  very  top  mounting  surface  of  the  bus  (designated  the  “payload  interface 
plate”)  serves  as  the  substructure  for  the  mission  modules.  Several  different  types  of 
mission  modules  may  be  evaluated  with  the  various  bus  designs  by  using  the  Modsat 
computer  model.  For  ease  of  evaluation  for  this  design  study,  the  mission  modules  are 
oriented  in  the  axial  direction  because  the  on-orbit  attitude  for  the  Modsat  will  have  the 
payload  interface  plate  pointing  nadir.  Future  design  efforts  may  introduce  alternative 
orientations. 

Finally,  it  was  necessary  to  keep  the  spacecraft  center  of  mass  as  close  as  possible 
to  its  central  axis.  Thus,  mass  symmetry  was  a  major  factor  in  the  placement  of 
components. 

17.5.1  Structure 

Based  upon  the  AV  requirements  given  for  the  tactical  profile  desired,  the  height 
of  the  first  component  plate  was  set,  and  the  initial  positioning  of  components  could 
commence.  The  MAXTAC  structure  is  shown  in  Figure  17-2. 
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17.5.2  Propulsion 

Figure  17-3  shows  the  propulsion  subsystem  integrated  into  the  structure. 


Figure  17-3;  MAXTAC  Propulsion  Subsystem 
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17.5.3  ADCS 


For  the  purpose  of  optimum  three-axis  control,  the  reaction  wheels  are  canted  at 
45  degree  angles.  The  sensor  components  are  placed  at  the  outer  edge  of  the  component 
plate,  such  that  they  have  a  field  of  view  through  holes  in  the  outer  bus  wall.  The  sensors 
face  directions  in  which  there  are  no  solar  arrays  blocking  the  view.  In  Figure  17-4,  the 
ADCS  components  are  shown  integrated  into  the  structure. 


Figure  17-4:  MAXTACADCS 

17.5.4  EPS 

Due  to  the  placement  of  the  reaction  wheels,  the  batteries  hang  from  the  bottom  of 
the  2nd  component  plate.  The  regulator  and  CPU  are  placed  symmetrically  where  space 
allows.  The  stowed  and  deployed  EPS  configurations  are  shown  in  Figure  17-5. 
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Figure  17-5:  MAXTACEPS 


17.5.5  TTC 

The  SGLS  antenna  on  the  third  component  level  is  placed  close  to  the  outer  edge 
of  the  bus.  This  antenna  must  be  deployed  on  a  boom  with  an  appropriate  mechanism. 
TT&C/CPU  components  are  shown  in  Figure  17-6. 


Figure  17-6:  MAXTAC  TT&C/CPU 
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17.5.6  MAXTAC  SMASH 


Figure  17-7  shows  the  top  level  of  the  bus,  with  the  SMASH  being  utilized  by  a 
high  data  rate  communications  package. 


Figure  17-7:  MAXTAC  SMASH 


17.5.7  MAXTAC  Composite 

The  entire  MAXTAC  design  is  shown  in  Figure  17-8.  The  primary 
characteristics  of  MAXTAC  are  listed  in  Table  17-42, 


Figure  17-8:  MAXTAC  (deployed) 
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Table  17-42:  Primary  Characteristics  of  MAXTAC 


Mass  (kg) 

262.5 

Height  of  bus  (cm) 

71 

Average  Power  (watts) 

447 

Peak  Power  (watts) 

1000 

17.6  Variations  on  the  Baseline 

17.6.1  MIDTAC 

The  MIDTAC  alternative  is  exactly  the  same  as  the  MAXTAC  bus,  except  that  the 
bottom  level  is  shorter  due  to  the  smaller  propellant  tanks. 


Figure  17-9:  MIDTAC  (deployed) 
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Table  17-43:  Primary  Characteristics  of  MIDTAC 


Mass  (kg) 

242.9 

Height  of  bus  (cm) 

68 

Average  Power  (watts) 

447 

Peak  Power  (watts) 

1000 

17.6.2  LOWTAC 

The  LOWTAC  bus  is  also  the  same  as  MAXTAC,  but  with  an  even  shorter  bottom 

level. 


Figure  17-10:  LOWTAC  (deployed) 


Table  17-44:  Primary  Characteristics  of  LOWTAC 


Mass  (kg) 

215.7 

Height  of  bus  (cm) 

63 

Average  Power  (watts) 

447 

Peak  Power  (watts) 

1000 

17.6.3  MACTAC-N 

In  the  next  three  alternatives,  the  layout  of  the  bottom  level  is  the  same  as  in  the 
previous  three  alternatives.  However,  there  is  no  SMASH.  In  fact,  since  the  removal  of 
the  SMASH  space  leaves  only  a  few  components  on  the  top  level,  these  components  were 
relocated  onto  the  second  level  to  reduce  the  height  of  the  bus.  But  the  height  of  the 
second  level  was  increased  in  order  to  fit  all  of  components  within. 
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Table  17-45:  Primary  Characteristics  of  MAXTAC-N 


Mass  (kg) 

256.1 

Height  of  bus  (cm) 

69 

Average  Power  (watts) 

447 

Peak  Power  (watts) 

1000 

17.6.4  MIDTAC-N 


Figure  17-12:  MIDTAC-N  (deployed) 

Table  17-46:  Primary  Characteristics  of  MIDTAC-N 


Mass  (kg) 

236.5 

Height  of  bus  (cm) 

66 

Average  Power  (watts) 

447 

Peak  Power  (watts) 

1000 
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17.6.5  LOWTAC-N 


Figure  17-13:  LOWTAC-N  (deployed) 

Table  17-47:  Primary  Characteristics  of  LOWTAC-N 


Mass  (kg) 

209.3 

Height  of  bus  (cm) 

61 

Average  Power  (watts) 

447 

Peak  Power  (watts) 

1000 

17.6.6  MIDTAC-23 

Finally,  a  23”  LV  interface  version  of  Modsat  was  created  simply  to  broaden  the 
solution  space  somewhat.  The  MIDTAC  platform  was  chosen,  although  any  of  the 
tactical  profiles  would  have  been  appropriate.  The  MIDTAC-23  bus  is  exactly  the  same 
as  the  MIDTAC  bus,  except  that  it  is  placed  higher  in  the  LV  due  to  the  interface. 
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Figure  17-14;  Mn)TAC-23  (deployed) 

Table  17-48:  Primary  Characteristics  of  MIDTAC-23 


Mass  (kg) 

292.8 

Height  of  bus  (cm) 

95.7 

Average  Power  (watts) 

390 

Peak  Power  (watts) 

950 

17.7  Summary 


To  primary  characteristics  of  each  alternative  are  summarized  in ,  where 

1=MAXTAC 
2  =  MIDTAC 
3=LOWTAC 
4  =  MAXTAC-N 
5=MIDTAC-N 

6  =  LOWTAC-N 

7  =  MIDTAC-23 
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Table  17-49:  Primaiy  Characteristics  of  All  Designs 


Characteristic 

1 

2 

3 

4 

5 

6 

7 

Mass  (kg) 

262.5 

242.9 

215.7 

256.1 

236.5 

209.3 

292.8 

Height  (cm) 

71 

68 

63 

69 

66 

61 

95.7 

Avg  Power  (W) 

447 

47 

447 

447 

447 

447 

390 

Peak  Power  (W) 

1000 

1000 

1000 

1000 

1000 

1000 

950 
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18.  System  Analysis 


This  section  explains  the  method  by  which  the  alternative  designs  were  compared 
and  rated.  The  key  factors  that  the  team  used  to  perform  the  analysis  are  discussed  for 
each  objective.  Finally,  the  results  of  the  analysis  are  presented. 

18.1  Definitions 

The  alternative  designs  are  classified  two  ways,  as  follows. 

•  Categories;  There  are  two  categories,  based  on  the  existence  of  the  third  level  of  the 
bus. 

Category  One  (Cat  1);  Includes  all  three-level/SMASH  designs.  These 
designs  are  designated  as  “fi-ee  space”  alternatives,  since  they  have  a  large, 
reserved  space  on  the  third  level.  This  space  is  recommended  for  a  dedicated 
high  data  rate  (HDR)  communications  package. 

=e>  Category  Two  (Cat  2);  Includes  all  two-level/No  SMASH  designs.  These 
designs  are  designated  as  “no  free  space”  alternatives,  since  there  is  no  third 
level  with  reserved  space.  Any  dedicated  HDR  communications  package  must 
be  integrated  into  the  mission  module. 

•  Tactical  Profiles:  There  are  three  profiles,  based  on  the  amount  of  AV  provided  by  the 
propulsion  subsystem. 

=^>  Profile  One:  100  m/s  of  AV,  for  little  or  no  plane  change  capability. 

Profile  Two:  300  m/s  of  AV,  for  1.5°  of  plane  change  at  350  km  altitude. 

=>  Profile  Three:  450  m/s  of  AV,  for  2.5°  of  plane  change  at  350  km  altitude. 
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18.2  Method 


In  the  following  analysis,  the  seven  design  alternatives  are  analyzed  objective  by 
objective.  For  each  objective,  the  team  evaluated  the  performance  of  each  alternative. 

For  objectives  with  natural  measures  of  effectiveness,  the  performance  value  was  obtained 
from  the  Modsat  model.  For  objectives  with  attribute  scale  MOEs,  the  team  rated  the 
performance  of  each  alternative  against  its  attribute  scale.  Ratings  were  given  by  group 
consensus,  which  was  reached  in  each  case  after  thorough  discussion.  The  scores  were 
assigned  to  each  alternative  individually;  however,  the  judgments  still  involved  many 
comparisons  between  the  alternatives.  It  was  discovered  that  for  many  objectives,  groups 
of  scores  could  be  assigned  by  category  or  profile,  depending  on  which  classification  was 
relevant  to  the  judgment.  Note  that  the  analysis  involved  only  the  bottom-level  objectives, 
since  only  these  objectives  have  MOEs. 

For  many  of  the  objectives,  there  was  no  distinguishable  difference  between  the 
alternatives.  This  possibility  was  discussed  in  Value  System  Design.  All  of  the  objectives 
were  critical  to  guiding  the  design  process,  and  the  tradeoffs  and  decisions  were  made  in 
accordance  with  these  objectives.  As  a  result  of  these  decisions,  the  alternative  solutions 
have  many  similar  characteristics,  and  perform  equally  well  in  several  of  the  objectives. 

But  the  Modsat  evaluation  model  requires  scores  for  each  objective;  thus,  in  such  cases, 
the  team  often  assigned  a  nominal  attribute  value  of  2.5  to  the  alternatives. 

18.3  Analysis 

1 .  Minimize  time  to  full  rate  production; 
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A  design  with  spread-out  and  accessible  components  performs  well  in  this 
attribute.  Cat  2  designs  are  more  difficult  to  manufacture/assemble,  since  the  components 
are  more  densely  grouped.  If  a  high  data  rate  communications  package  is  required,  which 
is  highly  likely  for  all  Modsat  mission,  the  Cat  2  configuration  will  require  the  mission 
module  package  to  incorporate  additional  communications  equipment.  Thus,  Cat  2 
designs  do  not  have  the  flexibihty  that  Cat  1  designs  do. 


Table  18-1:  Min  Time  to  Full  Rate  Production 


CAT  1 

CAT  2 

MAXTAC 

3.5 

2.5 

MAXTAC-N 

MIDTAC 

3.5 

2.5 

MIDTAC-N 

LOWTAC 

3.5 

2.5 

LOWTAC-N 

MIDTAC-23 

3.0 

2.  Minimize  research,  development,  test  and  engineering  cost  (numbers  obtained  from  the 
Modsat  cost  model): 


Table  18-2:  Min  RDT&E  Cost 


Design 

Cost  ($  million) 

MAXTAC 

77.50 

MIDTAC 

72.43 

LOWTAC 

64.74 

MAXTAC-N 

75.15 

MIDTAC-N 

70.10 

LOWTAC-N 

62.36 

MIDTAC-23 

70.70 

3.  Minimize  production  cost  (numbers  obtained  from  the  Modsat  cost  model): 
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Table  18-3;  Min  Production  Cost 


Design 

Cost  ($  million) 

MAXTAC 

30.09 

MIDTAC 

27.00 

LOWTAC 

21.71 

MAXTAC-N 

28.93 

MIDTAC-N 

25.80 

LOWTAC-N 

20.55 

MIDTAC-23 

26.71 

4.  Minimize  retirement  cost; 

The  more  fiiel  a  satellite  has,  the  more  flexible  are  its  options  for  retirement.  Fuel 
can  be  used  to  de-orbit  the  satellite,  or  to  boost  it  to  a  useless  orbit.  But  without  this 
fuel,  the  satellite  can  only  be  retired  gradually,  through  orbital  decay.  In  this  case,  if  the 
useful  life  of  the  satellite  has  expired,  it  remains  a  drain  on  tracking  resources.  Thus,  the 
scores  for  this  attribute  are  roughly  proportional  to  the  amount  of  fuel  used  in  each  design. 
The  following  scale  was  developed: 


Delta  velocity  (meters/seci  Score 


450  4.5 

300  3.0 

100  1.0 


Table  18-4;  Min  Retirement  Cost 


CAT  1 

CAT  2 

MAXTAC 

4.5 

4.5 

MAXTAC-N 

MIDTAC 

3.0 

3.0 

MIDTAC-N 

LOWTAC 

1.0 

1.0 

LOWTAC-N 

MIDTAC-23 

3.0 
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5.  Minimize  cost  of  telemetry,  tracking,  and  commanding: 

Cat  1  alternatives  guarantee  a  space  on  the  bus  that  can  be  used  for  a  dedicated 
HDR  package  for  the  user.  This  package  could  possibly  be  used  for  command  and 
control.  This  flexibility  with  regard  to  the  TT&C  function  gives  Cat  1  an  advantage  over 
Cat  2,  although  not  much  of  one.  as  part  of  the  TT&C  fimction.  Thus,  Cat  1  designs 
guarantee  more  options 


Table  18-5:  Min  Cost  of  TT&C 


CAT  1 

CAT  2 

MAXTAC 

3.5 

3.0 

MAXTAC-N 

MIDTAC 

3.5 

3.0 

MIDTAC-N 

LOWTAC 

3.5 

3.0 

LOWTAC-N 

MIDTAC-23 

3.5 

6.  Minimize  cost  of  mission  module  integration  and  system  test: 

Cat  1  alternatives  perform  somewhat  better  on  this  attribute  than  Cat  2 
alternatives.  Since  Cat  2  alternatives  do  not  have  the  free  space,  their  integration  with 
mission  modules  is  more  complicated.  This  is  due  to  the  fact  that  a  HDR  package,  or  any 
other  additional  components  which  could  have  been  placed  in  the  free  space,  must  be 
integrated  within  the  mission  module.  One  must  also  consider  the  additional  difficulty  of 
controlling  the  center  of  mass  when  placing  additional  components  in  the  mission  module. 
Also,  the  free  space  in  Cat  1  alternatives  allows  room  for  additional  components.  These 
components  can  be  incorporated  into  the  bus  and  fully  tested  prior  to  mission  module 
integration,  thereby  reducing  the  cost  of  the  integration  effort.  On  the  other  hand.  Cat  1 
alternatives  allow  for  more  variability  in  the  system  configuration,  which  would  increase 
the  workload  during  tests  of  the  integrated  satellite.  Also,  integration  and  test  efforts  for 
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Cat  1  alternatives  must  take  into  account  the  extra  equipment  and  its  associated  data  and 
power  lines. 


Table  18-6:  Min  Cost  of  Mission  Module  Integration  and  System  Test 


CAT  1 

CAT  2 

MAXTAC 

3.75 

3.0 

MAXTAC-N 

MIDTAC 

3.75 

3.0 

MDDTAC-N 

LOWTAC 

3.75 

3.0 

LOWTAC-N 

MIDTAC-23 

3.75 

7.  Minimize  cost  of  maintenance: 

Alternatives  with  smaller  fiael  tanks  and  better  access  for  removal  and  replacement 
of  components  perform  better  on  this  attribute.  Thus,  volume  of  fuel  and  number  of 
component  levels  are  key  elements.  In  Cat  1  designs,  the  components  are  less  densely 
packed  than  in  Cat  2  designs.  This  characteristic,  along  with  the  additional  plate,  allows 
for  easier  access  to  components.  It  was  decided  that  as  the  fuel  tanks  increase  in  volume 
and  weight,  their  maintenance  becomes  more  difficult.  The  tank  structures  are  larger  and 
therefore  harder  to  handle  and  transport.  Moreover,  the  additional  fuel  increases  the 
hazards  of  working  with  and  storing  hydrazine. 


Table  18-7:  Min  Cost  of  Maintenance 


CAT  1 

CAT  2 

MAXTAC 

4.0 

2.5 

MAXTAC-N 

MIDTAC 

4.5 

3.0 

MIDTAC-N 

LOWTAC 

5.0 

2.5 

LOWTAC-N 

MIDTAC-23 

4.5 

8.  Minimize  cost  of  storage,  handling,  and  transportation; 
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Although  Cat  1  and  Cat  2  are  not  vastly  different  in  this  objective,  the  additional 


complexity  of  the  more  compact  Cat  2  design  may  lead  to  more  precautions  and 
procedures  in  the  handling  and  transporting  of  Cat  2  spacecraft.  The  amount  of  on-board 
fuel  is  another  consideration.  Smaller  and  lighter  propulsion  tanks  imply  less  efibrt  in 
storage,  handling,  and  transportation.  Thus,  alternatives  with  smaller  tanks  and  more 
component  plates  perform  better  on  this  attribute. 

Table  18-8:  Min  Cost  of  Storage,  Handling,  and  Transportation 


CAT  1 

CAT  2 

MAXTAC 

3.0 

2.5 

MAXTAC-N 

MDDTAC 

3.5 

3.0 

MIDTAC-N 

LOWTAC 

4.0 

3.5 

LOWTAC-N 

MIDTAC-23 

3.5 

9.  Minimize  cost  of  launch  integration  and  test: 

Launch  integration  is  not  primarily  concerned  with  the  internal  makeup  of  the 
satellite.  However,  the  weight  and  size  of  the  satellite  are  key  factors.  Smaller  and  lighter 
satellites  perform  better  on  this  attribute.  Since  the  Cat  2  design  is  more  compact  and 
shorter  than  Cat  1 .  And  for  a  given  tactical  profile,  the  Cat  2  alternative  is  also  lighter 
than  the  Cat  1  alternative.  Thus,  it  is  easier  to  handle. 

Table  18-9:  Min  Cost  of  Launch  Integration  and  Test 


CAT  1 

CAT  2 

MAXTAC 

2.5 

3.0 

MAXTAC-N 

MIDTAC 

3.0 

3.5 

MIDTAC-N 

LOWTAC 

3.5 

4.0 

LOWTAC-N 

MIDTAC-23 

2.5 
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10.  Minimize  preparation  time  to  launch: 


Since  this  objective  covers  the  time  it  takes  a  bus  to  go  from  storage  to  launch,  the 
properties  of  weight,  height,  fuel  tank  size,  and  complexity  are  the  primary  considerations. 
Therefore,  the  scores  from  “minimize  cost  of  maintenance”  and  “minimize  cost  of  launch 
integration  and  test”  were  combined  and  averaged.  Shorter,  lighter,  and  less  compact 
satellites  perform  better  on  this  attribute. 


Table  18-10:  Min  Prep  Time  to  Launch 


CAT  1 

CAT  2 

MAXTAC 

3.25 

2.75 

MAXTAC-N 

MIDTAC 

3.75 

3.25 

MIDTAC-N 

LOWTAC 

4.25 

3.75 

LOWTAC-N 

MIDTAC-23 

3.5 

1 1 .  Maximize  capability  for  tactical  maneuvers; 

Alternatives  with  more  fuel  perform  better  on  this  attribute,  since  they  allow  for 
more  AV.  It  should  be  noted  that  slew  rate  is  an  important  factor  in  tactical  capability. 
However,  since  all  of  the  alternatives  have  the  same  actuator  system,  slew  rate  was 
ignored  for  this  analysis.  The  following  scale  was  developed: 


Delta  velocity  (meters/secl  Score 


450  4.5 

300  3.0 

100  1.0 
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Table  18-11:  Max  Capability  for  Tactical  Maneuvers 


CAT  1 

CAT  2 

MAXTAC 

4.5 

4.5 

MAXTAC-N 

MIDTAC 

3.0 

3.0 

MIDTAC-N 

LOWTAC 

1.0 

1.0 

LOWTAC-N 

MIDTAC-23 

3.0 

12.  Minimize  data  latency: 

For  a  given  HDR  communications  package,  data  latency  is  not  affected  by  whether 
this  package  is  placed  on  the  mission  module  or  on  the  bus.  All  other  factors  that  could 
affect  data  latency  are  the  same  for  all  alternatives.  Therefore,  a  nominal  score  of  2.5  was 
assigned  to  each  design. 


Table  18-12:  Min  Data  Latency 


CAT  1 

CAT  2 

MAXTAC 

2.5 

2.5 

MAXTAC-N 

MIDTAC 

2.5 

2.5 

MIDTAC-N 

LOWTAC 

2.5 

2.5 

LOWTAC-N 

MIDTAC-23 

■ 

2.5 

13.  Maximize  reliability: 

All  of  the  designs  use  the  same  set  of  components.  Therefore,  it  was  assumed  for 
this  preliminary  analysis  that  all  designs  would  have  the  same  reliability.  Equal  values 
were  entered  into  the  model  in  the  form  of  a  nominal  attribute  scale  number. 
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Table  18-13:  Max  Reliability 


CAT  1 

CAT  2 

MAXTAC 

2.5 

2.5 

MAXTAC-N 

MIDTAC 

2.5 

2.5 

MIDTAC-N 

LOWTAC 

2.5 

2.5 

LOWTAC-N 

MIDTAC-23 

2.5 

14.  Maximize  survivability: 

The  additional  size  and  electrical  wiring  of  the  Cat  1  alternatives  make  them  more 
susceptible  to  enemy-directed  radiation,  EMP,  etc.,  than  Cat  2  alternatives.  However, 
designs  with  more  fuel  are  more  able  to  perform  evasive  maneuvers  in  order  to  avoid 
ASAT  attacks.  Satellites  with  more  fuel  and  a  more  compact  frame  perform  better  on  this 
attribute. 


Table  18-14:  Max  Survivability 


CAT  1 

CAT  2 

MAXTAC 

4.25 

4.5 

MAXTAC-N 

MIDTAC 

2.75 

3.0 

MIDTAC-N 

LOWTAC 

0.75 

1.0 

LOWTAC-N 

MIDTAC-23 

2.75 

15.  Minimize  cost  risk: 

The  cost  estimating  relationships  used  for  this  study  assume  the  use  of  standard 
components  and  production  methods.  Cat  2  designs  follow  the  more  traditional  method 
of  building  a  satellite.  Thus,  the  team  has  more  confidence  in  the  cost  estimates  of  Cat  2 
designs,  over  the  more  non-traditional  Cat  1  designs. 


329 


Table  18-15:  Min  Cost  Risk 


CAT  1 

CAT  2 

MAXTAC 

2.5 

3.5 

MAXTAC-N 

MIDTAC 

2.5 

3.5 

MIDTAC-N 

LOWTAC 

2.5 

3.5 

LOWTAC-N 

MIDTAC-23 

2.5 

16.  Minimize  performance  risk: 

Since  all  the  designs  were  built  with  the  same  components,  there  is  no  appreciable 
difference  between  them  with  respect  to  this  attribute.  However,  more  detailed  modeling 
at  some  point  in  the  future  may  reveal  greater  risk  in  the  more  non-traditional  approach  of 
the  Cat  1  design. 


Table  18-16:  Min  Performance  Risk 


CAT  1 

CAT  2 

MAXTAC 

2.5 

2.5 

MAXTAC-N 

MIDTAC 

2.5 

2.5 

MIDTAC-N 

LOWTAC 

2.5 

2.5 

LOWTAC-N 

MIDTAC-23 

2.5 

17.  Minimize  schedule  risk: 

In  the  Cat  2  configuration,  components  are  placed  very  close  together.  This  may 
lead  to  unexpected  problems  with  construction,  integration,  and  test.  Moreover,  any 
unforeseen  changes  to  the  design  would  be  extremely  difficult  to  implement,  and  would 
require  a  great  deal  of  re-engineering.  Therefore,  less  confidence  should  be  placed  in 
development/production/test  schedules  for  Cat  2  alternatives,  than  for  Cat  1  alternatives. 
The  roominess  of  the  Cat  1  designs  give  them  an  advantage  in  this  area,  since  changes  in 
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the  design  could  be  more  easily  implemented.  However,  the  allowed  variation  in  the 
configurations  of  the  Cat  1  designs  may  make  them  vulnerable  to  unexpected  delays. 


Table  18-17:  Min  Schedule  Risk 


CAT  1 

CAT  2 

MAXTAC 

3.5 

2.0 

MAXTAC-N 

MEDTAC 

3.5 

2.0 

MIDTAC-N 

LOWTAC 

3.5 

2.0 

LOWTAC-N 

MIDTAC-23 

3.5 

18.  Maximize  pointing  accuracy; 

Since  all  of  the  alternatives  have  the  same  suite  of  sensors  an  actuators,  there  is  no 
difference  between  them  wdth  respect  to  this  attribute.  Thus,  equal  values  were  entered 
into  the  model  in  the  form  of  a  nominal  attribute  scale  number. 


Table  18-18:  Max  Pointing  Accuracy 


CAT  1 

CAT  2 

MAXTAC 

2.5 

2.5 

MAXTAC-N 

MIDTAC 

2.5 

2.5 

MIDTAC-N 

LOWTAC 

2.5 

2.5 

LOWTAC-N 

MIDTAC-23 

2.5 

19.  Maximize  data  storage: 

All  of  the  designs  allow  for  two  gigabytes  of  storage.  Thus,  equal  values  were 
entered  into  the  model  in  the  form  of  a  nominal  attribute  scale  number. 
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Table  18-19:  Max  Data  Storage 


CAT  1 

CAT  2 

MAXTAC 

2.5 

2.5 

MAXTAC-N 

MIDTAC 

2.5 

2.5 

MIDTAC-N 

LOWTAC 

2.5 

2.5 

LOWTAC-N 

MIDTAC-23 

2.5 

20.  Maximize  average  mission  module  power: 

For  all  designs  except  MIDT AC-23,  the  same  amount  of  surface  area  is  provided 
for  the  solar  arrays.  MIDT  AC-23  has  less  available  height  for  the  stowed  arrays;  thus,  it 
has  less  surface  area  and  does  not  generate  as  much  power.  Average  available  power  is 
shown  in  Table  18-20  (numbers  obtained  from  Modsat  model). 


Table  18-20:  Max  Average  Mission  Module  Power 


Design 

Power  (watts) 

MAXTAC 

319.2 

MIDTAC 

319.2 

LOWTAC 

319.2 

MAXTAC-N 

319.2 

MIDTAC-N 

319.2 

LOWTAC-N 

319.2 

MIDTAC-23 

261.9 

21.  Maximize  allowable  mission  module  weight  numbers  obtained  from  Modsat  model): 
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Table  18-21:  Max  Allowable  Mission  Module  Weight 


Design 

Weight  (kg) 

MAXTAC 

40.50 

MIDTAC 

60.56 

LOWTAC 

87.75 

MAXTAC-N 

47.51 

MIDTAC-N 

67.27 

LOWTAC-N 

94.76 

MIDTAC-23 

64.91 

22.  Maximize  adaptability: 

With  the  additional  plate  and  free  space  in  the  Cat  1  designs,  the  satellite  integrator 
has  more  flexibility  in  placing  additional  components  on  the  bus.  Alternatives  with  more 
fuel  are  more  adaptable  to  changes  in  mission  profiles. 


Table  18-22:  Max  Adaptability 


CAT  1 

CAT  2 

MAXTAC 

4.5 

3.0 

MAXTAC-N 

MIDTAC 

4.0 

2.5 

MIDTAC-N 

LOWTAC 

3.5 

1.5 

LOWTAC-N 

MIDTAC-23 

4.0 

23.  Maximum  orbital  accuracy: 

All  of  the  alternatives  were  given  enough  fuel,  in  addition  to  that  reserved  for 
tactical  maneuvering,  to  maintain  orbit  at  350  km  for  one  year.  Thus,  there  is  no 
difference  between  the  alternatives  with  respect  to  this  attribute.  Equal  values  were 
entered  into  the  model  in  the  form  of  a  nominal  attribute  scale  number. 
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Table  18-23:  Max  Orbital  Accuracy 


CAT  1 

CAT  2 

MAXTAC 

2.5 

2.5 

MAXTAC-N 

MIDTAC 

2.5 

2.5 

MIDTAC-N 

LOWTAC 

2.5 

2.5 

LOWTAC-N 

MIDTAC-23 

2.5 

24.  Maximize  data  down-link  rate: 

All  of  the  alternatives  could  incorporate  the  same  HDR  communications  package. 
The  location  of  this  package  on  the  satellite  should  not  affect  its  throughput  performance. 
Thus,  there  is  no  difference  between  the  alternatives  with  respect  to  this  attribute.  Equal 
values  were  entered  into  the  model  in  the  form  of  a  nominal  attribute  scale  number. 


Table  18-24:  Max  Data  Down-link  Rate 


CAT  1 

CAT  2 

MAXTAC 

2.5 

2.5 

MAXTAC-N 

MIDTAC 

2.5 

2.5 

MIDTAC-N 

LOWTAC 

2.5 

2.5 

LOWTAC-N 

MIDTAC-23 

2.5 

25.  Maximize  peak  mission  module  power: 

Refer  to  the  discussion  for  objective  20,  “maximize  average  mission  module 
power.”  Numbers  in  Table  18-25  were  obtained  from  the  Modsat  model. 
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Table  18-25:  Max  Peak  Mission  Module  Power 


Design 

Power  (watts) 

MAXTAC 

872.2 

MIDTAC 

872.2 

LOWTAC 

872.2 

MAXTAC-N 

872.2 

MIDTAC-N 

872.2 

LOWTAC-N 

872.2 

MIDTAC-23 

814.9 

26.  Maximize  allowable  mission  module  volume  (numbers  obtained  from  Modsat  model); 


Table  18-26  Max  Allowable  Mission  Module  Volume 


Design 

Volume  (m^) 

MAXTAC 

0.7616 

MIDTAC 

0.7855 

LOWTAC 

0.8094 

MAXTAC-N 

0.7825 

MIDTAC-N 

0.8005 

LOWTAC-N 

0.8304 

MIDTAC-23 

0.7855 

27.  Minimize  thermal  transfer: 

Since  the  components  in  the  Cat  1  designs  are  more  spread  out,  they  are  less  likely 
to  be  thermally  impacted  by  neighboring  components  than  are  components  in  the  Cat  2 
designs.  A  decrease  in  the  cross-sectional  area  of  the  satellite  reduces  the  amount  of  solar 
absorption. 
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Table  18-27:  Min  Thermal  Transfer 


CAT  1 

CAT  2 

MAXTAC 

3.0 

2.0 

MAXTAC-N 

MIDTAC 

3.5 

2.5 

MIDTAC-N 

LOWTAC 

4.0 

3.0 

LOWTAC-N 

MIDTAC-23 

3.5 

18.4  Results 


The  main  results  for  each  alternative  are  presented  below  in  Table  18-28,  Table 
18-29,  and  Figure  18-1.  The  scores  were  obtained  from  the  Modsat  model.  The  scores 
listed  under  each  main  objective  in  Table  18-28  are  weighted  scores;  that  is,  they  are  the 
result  of  multiplying  the  utility  scores  for  a  given  objective  by  that  objective’s  weight.  For 
a  given  alternative,  the  sum  of  the  weighted  scores  for  each  main  objective  yields  the 
overall  utility  score  in  the  final  column. 


Table  18-28  Weighted  Scores:  Standard  Weights 


Weight 

0.1382 

0.3119 

0.1527 

0.1746 

0.2226 

Cost 

Responsiveness 

Risk 

Availability 

Utility 

Total 

MAXTAC 

0.07329 

0.2038 

0.1048 

0.1131 

0.1123 

0.6073 

MIDTAC 

0.09589 

0.1835 

0.1048 

0,1058 

0.1309 

0.6209 

LOWTAC 

0.1165 

0.1546 

0.1048 

0,06152 

0.151 

0.5884 

MAXTAC-N 

0.07378 

0.1962 

0.1054 

0.1169 

0.1134 

0,6057 

MIDTAC-N 

0.09354 

0.1763 

0.1054 

0.0947 

0.1296 

0.5995 

LOWTAC-N 

0.1098 

0.1469 

0.1054 

0.06507 

0.152 

0.5792 

MIDTAC-23 

0.09937 

0.18 

0.1048 

0.09085 

0.09914 

0.5742 

The  final  scores  for  each  alternative  are  presented  in  again  in  Table  18-29,  where 


the  alternatives  have  been  ranked.  The  MIDTAC  design  scores  higher  than  the  other 


alternatives.  This  comparison  is  clearer  in  Figure  18-1 . 


Many  factors  combined  to  give  the  MIDTAC  alternative  the  highest  score.  This 


design  fared  well  in  the  trade-off  between  tactical  responsiveness  and  mission  utility,  the 


two  highest-weighted  objectives.  In  the  other  three  objectives,  which  are  lower-weighted 


336 


and  therefore  less  influential,  MIDTAC  scored  in  the  middle  of  the  alternatives.  The 
MAXTAC  alternative  also  fared  well,  receiving  the  second  highest  score.  This  is  primarily 
due  to  its  tactical  responsiveness,  by  far  the  highest-weighted  objective  in  this  study.  The 
MIDTAC-23  alternative  fared  the  worst  of  the  designs.  It  did  not  score  near  the  top  for 
any  of  the  objectives,  and  received  a  very  low  score  for  mission  utility,  the  second-highest 
weighted  objective  of  this  study.  This  is  because  it  used  a  great  deal  more  of  the  launch 
vehicle  fairing  volume,  and  therefore  reduced  the  area  available  for  the  solar  arrays. 


Table  18-29:  Ranking  of  Alternatives;  Standard  Weights 


1 

MIDTAC 

0.6209 

MAXTAC 

0.6073 

MAXTAC-N 

0.6057 

MIDTAC-N 

mEm 

LOWTAC 

LOWTAC-N 

Bn 

MIDTAC-23 

Standard  Weights 


0.5400  0.5600  0.5800  0.6000  0.6200  0.6400 


MAXTAC 

MIDTAC 

LOWTAC 

MAXTAC-N 

MIDTAC-N 

LOWTAON 

MIDTAC-23 


Figure  18-1:  Performance  at  Standard  Weights 
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19.  Decision  Making 


The  puq)ose  of  this  chapter  is  to  provide  the  chief  decision  maker  with  additional 
information  that  will  aid  in  the  making  of  decisions  regarding  the  implementation  of  this 
program.  The  results  of  the  previous  chapter  revealed  that  the  MIDTAC  alternative 
appears  to  be  the  best  solution.  However,  these  results  are  dependent  on  several  factors, 
the  chief  factor  being  the  values  of  the  priority  weights  for  the  objectives.  It  should  be 
noted  that  these  priority  weights  were  determined  through  subjective  judgments.  As 
mentioned  earlier  in  the  study,  these  judgments  were  submitted  at  a  given  time,  under  a 
given  set  of  technological,  political,  and  other  environmental  factors.  Thus,  the  analysis 
discussed  in  this  chapter  was  performed  in  order  to  demonstrate  the  sensitivity  of  the 
results  to  changes  in  the  objective  weights,  due  to  shifting  environmental  factors. 

19.1  Sensitivity  Analysis 

In  this  analysis,  environmental  scenarios  were  created  in  order  to  examine  the 
effect  of  changes  in  the  top-level  objective  weights.  In  each  scenario,  the  weight  of  one  of 
the  objectives  was  increased  to  correspond  with  a  certain  environmental  situation.  The 
weights  of  the  four  remaining  objectives  were  scaled  down  proportionally,  so  that  all  of 
the  weights  would  still  sum  to  one.  With  the  new  weights,  the  overall  utility  function  was 
performed  on  each  of  the  alternatives,  and  the  results  were  recorded.  In  some  cases,  an 
alternative  other  than  MIDTAC  received  the  highest  score.  The  first  five  scenarios  were 
created  by  multiplying  the  weights  of  one  of  the  five  top-level  objectives  by  two,  and  re- 
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scaling  the  other  four  objective  weights  accordingly.  In  the  final  “extreme  cost”  scenario, 
the  cost  objective  was  given  a  weight  of  0.5. 

19.1.1  Cost  Scenario 

In  the  original  set  of  weights,  the  minimization  of  cost  was  given  relatively  low 
priority.  It  is  conceivable  that  this  objective  could  become  much  more  important  due  to 
cuts  in  the  budget  and  other  funding  problems.  Therefore,  the  cost  weight  was  doubled  to 
0.2764.  Table  19-30  and  Figure  19-1  below  demonstrate  the  performance  of  the 
alternatives  under  this  scenario.  MIDTAC  still  received  the  highest  score.  In  this 
scenario,  cost  and  responsiveness  are  the  two  highest-weighted  objectives,  and  the 
MIDTAC  alternative  optimizes  the  trade-off  between  these  two  factors.  The  LOWTAC 
alternative  replaced  MAXTAC  with  the  second  highest  score.  This  is  not  surprising,  since 
MAXTAC  receives  a  low  utility  score  for  cost,  which  is  more  heavily  weighted  in  this 
scenario. 


Table  19-30:  Weighted  Scores;  Cost  x  2 


Weight 

0.2764 

0.2688 

0.1316 

0.1505 

0.1918 

Cost 

Responsiveness 

Risk 

Availability 

Utility 

Total 

MAXTAC 

0.08802 

0.09494 

0.09432 

0.5950 

MIDTAC 

0.08802 

0.08885 

0.1099 

LOWTAC 

0.08802 

0.05165 

0.1268 

0.6294 

MAXTAC-N 

0.1647 

0.08848 

0.09817 

0.09519 

0.5940 

MIDTAC-N 

0.148 

0.08848 

0.07952 

0.1088 

0.6119 

LOWTAC-N 

0.2195 

0.1233 

0.08848 

0.05464 

0.1277 

0.6136 

MIDTAC-23 

0.1987 

0.1511 

0.08802 

0.07628 

0.08324 

0.5973 
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Costx  2 

0.5700  0,5800  0.5900  0.6000  0.6100  0.6200  0.6300  0.6400 
MAXTAC 
MDTAC 
LOWTAC 
MAXTAC-N 
MIDTAC-N 
LOWTAC-N 
MIDTAC-23 


Figure  19-1:  Performance  at  Cost  x  2 
19.1.2  Responsiveness  Scenario 

Tactical  responsiveness  may  become  more  important  due  to  a  proliferation  of 
situations  and  conflicts  around  the  world  where  US  interests  are  threatened.  In  this 
scenario,  the  weight  of  the  responsiveness  objective  was  doubled  to  0.6238.  Table  19-3 1 
and  Figure  19-2  below  show  how  the  alternatives  performed.  It  is  not  surprising  that  the 
two  MAXTAC  alternatives  received  the  highest  scores,  since  they  were  specifically 
designed  for  responsiveness.  Within  each  category  (see  the  previous  chapter  for  a 
definition  of  categories),  the  scores  decrease  with  less  propulsion  capability. 


Table  19-31:  Weighted  Scores;  Responsiveness  x  2 


Weight 

0.0951 

0.6238 

0,1051 

0.1201 

0.1532 

Cost 

Risk 

Availability 

Utility 

Total 

MAXTAC 

0.04007 

0.4075 

0.06182 

0.06142 

0.6281 

MIDTAC 

0.05243 

0.367 

0.05785 

0.07154 

0.6061 

LOWTAC 

0.06372 

0.3092 

0.03363 

0.08257 

0.5464 

MAXTAC-N 

0.04034 

0.3923 

0.06393 

0.06199 

0.6162 

MIDTAC-N 

0.05114 

0.3526 

0.05178 

0.07087 

0.5840 

LOWTAC-N 

0.06002 

0.2937 

■TmW 

0.03558 

0.08312 

0.5300 

MIDTAC-23 

0.05433 

0.3599 

0.04967 

0.05421 

0.5754 
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Figure  19-2:  Performance  at  Responsiveness  x  2 
19.1.3  Risk  Scenario 

Any  number  of  budgetary,  schedule,  and  performance-related  constraints  and 
limitations  may  combine  to  give  the  minimization  of  cost,  schedule,  and  performance  risk  a 
higher  priority.  For  instance,  the  space  program  could  experience  a  series  of  expensive 
and  spectacular  failures,  which  would  tend  to  make  program  managers  much  more  averse 
to  risk.  In  this  scenario,  the  weight  of  the  risk  objective  was  doubled  to  0.3054.  Table 
19-32  and  Figure  19-3  below  show  how  the  alternatives  performed.  Again,  the  MIDTAC 
and  MAXTAC  alternatives  received  the  highest  score.  Since  the  weighted  risk  scores 
were  and  still  are  equal  for  the  designs  within  a  category,  and  since  there  is  little  difference 
between  these  scores  across  categories,  it  is  not  surprising  that  this  scenario  does  not 
change  the  ranking  of  the  alternatives.  However,  note  that  the  Cat  2  designs  score 
somewhat  higher  in  this  scenario,  since  they  perform  better  in  the  risk  objective  than  the 
Cat  1  designs. 
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Table  19-32:  Weighted  Scores;  Risk  x  2 


Weight 

0.1171 

1  0.26427  1 

0.3054 

0.14794 

0.18861 

Cost 

Risk 

Availability 

Utility 

Total 

MAXTAC 

0.0593 

0.1649 

0.2158 

0.09149 

0.09089 

0.6224 

MIDTAC 

0.07759 

0.1485 

0.2158 

0.08562 

0.1059 

0.6334 

LOWTAC 

0.09431 

0.1251 

0.2158 

0.04978 

0.1222 

0.6072 

MAXTAC-N 

0.0597 

0.1587 

0.217 

0.09461 

0.09174 

0.6218 

MIDTAC-N 

0.07569 

0.1427 

0.217 

0.07663 

0.1049 

0.6169 

LOWTAC-N 

0.08882 

0.1189 

0.217 

0.05265 

0.123 

0.6004 

MIDTAC-23 

0.0804 

0.1456 

0.2158 

0.07351 

0.08022 

0.5955 

Risk  X  2 

0.5700  0.5800  0.5900  0.6000  0.6100  0.6200  0.6300  0.6400 
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MIDTAC 
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Figure  19-3:  Performance  at  Risk  x  2 
19.1.4  Availability  Scenario 

Availability  could  become  more  important  for  several  reasons.  Air  Force  doctrine 
could  call  for  more  space  support  of  long-term  regional  conflicts  and  peacekeeping 
missions  (such  as  the  Middle  East,  Bosnia,  etc.),  in  which  case  high  system  lifetimes, 
reliability,  and  survivability  would  be  an  asset.  Or  a  leader  in  the  chain  of  command  over 
the  Modsat  program  could  adopt  a  conservative  stance  and  request  all  programs  to  focus 
more  on  reliability  and  survivability.  In  this  scenario,  the  weight  of  the  availabiUty 
objective  was  doubled  to  0.3492.  Performance  of  the  alternatives  is  shown  in  Table  19-33 
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and  Figure  19-4.  MAXTAC-N,  MIDTAC,  and  MAXTAC  received  the  top  scores,  in  that 
order.  Note  that  MAXTAC-N  has  the  highest  score  under  the  availability  objective. 


Table  19-33:  Weighted  Scores;  Availability  x  2 


Weight 

0.11407 

0.25744 

0.12604 

0.3492 

0.18373 

Cost 

Responsiveness 

Risk 

Availability 

Utility 

Total 

MAXTAC 

0.05778 

0.1607 

0.08265 

0.08857 

0.6159 

MIDTAC 

0.0756 

0.1447 

0.08265 

0.1032 

0.6178 

LOWTAC 

0.09189 

0.1219 

0.08265 

0.123 

0.1191 

0.5385 

MAXTAC-N 

0.05817 

0.1547 

0.08309 

0.2339 

0.08939 

0.6193 

MIDTAC-N 

0.07375 

0.139 

0.08309 

0,1894 

0.1022 

0.5874 

LOWTAC-N 

0.08655 

0,1158 

0.08309 

0.1302 

0.1199 

0.5355 

MIDTAC-23 

0.07835 

0.1419 

0.08265 

0.1817 

0.07817 

0.5628 

Availability  x  2 
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Figure  19-4:  Performance  at  Availability  x  2 
19.1.5  Utility  Scenario 

Many  factors  could  combine  to  give  mission  utility  a  higher  priority.  The 
standardized  approach  could  become  quite  appealing  to  mission  program  managers, 
making  Modsat  a  sought-after  platform.  In  this  case,  maximum  mission  functionality 
would  become  even  more  important.  In  this  scenario,  the  weight  of  the  mission  utility 
objective  was  doubled  to  0.4452.  The  alternatives  performed  as  shown  in  Table  19-34 
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and  Figure  19-5.  LOWTAC  received  the  highest  score,  while  MIDTAC  placed  second. 
In  general,  the  smaller  satellites  did  well  in  this  scenario.  This  is  primarily  due  to  their 
allowance  for  more  weight  and  volume  in  the  mission  module,  these  attributes  being  key 
sub-objectives  under  mission  utility. 


Table  19-34:  Weighted  Scores;  Utility  x  2 


Weight 

0.10744 

0.24247 

0.11871 

0.13573 

0.4452 

Cost 

Responsiveness 

Risk 

Utility 

Total 

MAXTAC 

0.0523 

0.1454 

0.07481 

0.08069 

0.2247 

0.5779 

MIDTAC 

0.06843 

0.131 

0.07481 

0.07551 

0.2617 

0.6115 

LOWTAC 

0.08317 

0.1103 

0.07481 

0.0439 

0.3021 

0.6143 

MAXTAC-N 

0.05265 

0.14 

0.0752 

0.08344 

0.2268 

0.5781 

MIDTAC-N 

0.06675 

0.1258 

0.0752 

0.06758 

0.2593 

0.5946 

LOWTAC-N 

0.07834 

0.1048 

0.0752 

0.04644 

0.3041 

0.6089 

MIDTAC-23 

0.07091 

0.1284 

0.07481 

0.06483 

0.1983 

0.5373 

MAXTAC 

MIDTAC 

LOWTAC 

MAXTAC-N 

MIDTAC-N 

LOWTAC-N 

MIDTAC-23 
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Figure  19-5:  Performance  at  Utility  x  2 


19.1.6  Extreme  Cost  Scenario 


This  scenario  was  created  to  examine  the  effect  of  placing  extreme  importance  on 


minimi23ng  cost.  This  environment  could  exist  in  the  case  of  a  long  term  budget  crisis,  or 


a  severe  dovra-sizing  of  the  military.  In  general,  the  priority  placed  on  the  cost  objective  is 


the  most  susceptible  to  change  among  the  top-level  objectives.  Therefore,  it  was  decided 
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that  this  investigation  would  add  value  to  the  sensitivity  analysis.  In  this  scenario,  the  cost 
objective  was  given  a  weight  of  0.5.  The  performance  of  the  alternatives  is  shown  in 
Table  19-35  and  Figure  19-6.  The  LOWTAC  alternative  received  the  highest  score.  This 
design  dominated  in  performance  of  the  cost  objective,  due  to  its  small  size  and  low  cost 
of  pre-launch  operations. 


Table  19-35:  Weighted  Scores;  50  %  Cost 


Weight 

0.5 

1  0.19905  1 

0.09745 

1  0.11143  i 

0.14206 

Cost 

Risk 

Utility 

Total 

MAXTAC 

0.2651 

0.1182 

0.06082 

0.0656 

0.06517 

0.5750 

MIDTAC 

0.3469 

0.1065 

0.06082 

0.06139 

0.07592 

0.6515 

LOWTAC 

0.4216 

0.08971 

0.06082 

0.03569 

0.08762 

0.6954 

MAXTAC-N 

0.2669 

0.1138 

0.06114 

0.06784 

0.06578 

0.5755 

MIDTAC-N 

0.3384 

0.1023 

0.06114 

0.05494 

0.0752 

0.6320 

LOWTAC-N 

0.3971 

0.08522 

0.06114 

0.03775 

0.08821 

0.6694 

MIDTAC-23 

0.3595 

0.1044 

0.06082 

0.05271 

0.05752 

0.6350 

SO  %  Cost 


O.OCKX)  0.1000  0.2000  0.3000  0.4000  0.5000  0.6000  0.7000 


Figure  19-6:  Performance  at  50  %  Cost 


19.2  Conclusion 

The  rankings  of  the  alternatives,  for  all  scenarios,  are  shown  below  in  Table  19-36. 
The  MIDTAC  alternative  is  the  best  solution.  It  scored  in  the  top  three  in  every  scenario. 
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with  three  first  place  finishes,  two  second  place  finishes,  and  two  third  place  finishes.  The 
ranks  for  each  alternative,  summed  over  all  the  scenarios,  are  calculated  in  Table  19-37. 
These  results  further  portray  MIDTAC  as  the  superior  alternative.  It  is  a  well-rounded 
design  that  optimizes  the  tradeoffs  between  the  objectives.  Its  performance  in  both  the 
responsiveness  and  utility  objectives,  the  two  most  critical  attributes  of  the  study. 


contributes  to  its  high  score.  Note  that  MIDTAC  scores  well  in  both  the  responsiveness 


and  utility  scenarios,  while  the  other  alternatives  fail  to  do  so. 


Table  19-36:  Sensitivity  Analysis;  Ail  Environments 


F6ri< 

starts 

QAx2 

tepcreivenesBxZ 

I«<x2 

A/al3tiljtyx2 

Llilityx2 

aD%G« 

1 

MDTSC 

tAmc 

M“xnec 

MDT/C 

LCWA2 

lcwta:; 

m<XfC 

iONTPC 

M»xrA:>N 

mufc 

MDTAD 

Monoc 

IQ/WCN 

mdfCM 

lONTfCH 

MDT/C 

mCTfC 

lo/vr/scN 

MDTAC 

MOnoCN 

MDT/CN 

MOnsCN 

MOr/CN 

MDTACN 

MDT/SCN 

MDr/C-23 

iONTfiC 

MOTfC-Z 

MDrAC-23 

ICVOTC 

MOT023 

MWAIiN 

M[m>N 

iONTfCH 

liimfC 

lONTPC 

ICWCN 

Lcmsc 

M»xrA2 

lUWOVCN 

■1 

MDTfiC-Z 

iim/CN 

[DmCN 

MUTPC-Z 

IXVWCN 

MDTfOZ 

IWWAC 

Table  19-37:  Sum  of  Rankings  for  the  Alternatives 


Alternative 

Calculation 

Sum 

MAXTAC 

2+6+ 1 +2+3 +6+7 

27 

MIDTAC 

1+1+3+1+2+2+3 

13 

LOWTAC 

5+2+6+5+6+1+1 

26 

MAXTAC-N 

3+7+2+3+1+5+6 

27 

MIDTAC-N 

4+4+4+4+4+4+5 

29 

LOWTAC-N 

6+3+7+6+7+3+2 

34 

MIDTAC-23 

7+5+5+7+5+7+4 

40 
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20.  Implementation 


This  section  is  intended  to  aid  the  CDM  in  the  implementation  of  the  results  of  the 
Modsat  study.  As  the  purpose  of  the  study  was  to  perform  high-level  systems 
engineering,  the  continuation  of  the  Modsat  program  will  require  much  more  detailed 
design  effort.  Moreover,  the  scope  of  this  study  was  limited  to  the  design  of  a  spacecraft 
bus.  Many  factors  and  fimctions  must  eventually  be  considered  and  designed  in  support  of 
Modsat  operations.  Recommendations  from  the  team  are  included  summarized  as  an 
overall  “concept  of  operations,”  and  are  discussed  below. 

20.1  Continued  Design  Effort 

The  systems  engineering  process  is  iterative  and  converging  in  nature.  The  scope 
of  each  iteration  of  the  design  process  depends  on  the  current  stage  within  the  life-cycle  of 
the  program.  As  the  life-cycle  progresses,  the  design  process  become  more  detailed. 
Eventually,  the  effort  converges  on  an  accepted  detailed  design. 

The  design  information  included  in  this  study  is  relevant  for  the  first  stage  of  the 
potential  life-cycle  of  Modsat.  In  this  stage,  sometimes  called  “concept  exploration,”  the 
systems  engineer  “identifies  all  reasonable  system  alternatives  that  may  satisfy  the  mission 
need  and  makes  recommendations...;  the  [CDM]  then  selects  those  alternatives  or 
concepts  which  meet  [the]  objectives”  (Systems  Engineering  Management  Guide,  1989:2- 
4).  If  the  Modsat  program  is  to  progress  further,  the  CDM  must  build  on  the  concepts 
and  recommendations  included  in  this  study. 

In  the  next  iteration  of  the  design  process,  engineers  must  revisit  the  selection  of 
components  for  Modsat,  with  a  view  toward  optimizing  the  MIDTAC  design.  Interfaces 
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must  be  designed,  at  the  subsystem  and  component  level.  In  particular,  command, 
telemetry,  power,  and  other  signal  flows  must  be  examined.  The  design  of  software  must 
begin,  within  the  context  of  the  modular  satellite  operating  system  recommended  by  this 
study.  Prototype  hardware  should  be  developed  to  demonstrate  the  functionality  of  some 
of  the  unique  aspects  of  Modsat,  such  as  its  cage  structure,  or  its  wrap-around  modular 
solar  array  assemblies. 

At  the  system  level,  the  mass  properties  (center  of  mass,  inertia  matrix,  etc.)  must 
be  carefully  examined  for  their  effect  on  stability  and  control.  Control  logic  should  be 
developed  to  model  the  attitude  control  function  of  Modsat.  Thermal  characteristics 
should  be  modeled  in  more  detail,  and  a  thermal  control  system  should  be  designed. 

The  continued  systems  engineering  effort  on  Modsat  must  incorporate  concurrent 
engineering,  wherein  current  engineering  efforts  reflect  consideration  of  manufacturing, 
testing,  logistics,  operational  support,  etc. 

The  items  mentioned  above  are  just  a  few  of  the  many  challenges  awaiting  the 
further  design  of  Modsat. 

20.2  Concept  of  Operations  (CONOPS) 

The  design  of  a  satellite  comprises  one  of  the  many  engineering  efforts  necessary 
for  the  operation  of  a  complete  space  system  architecture.  The  full  architecture 
encompasses  not  only  the  design  of  the  spacecraft  and  its  mission-specific  equipment,  but 
also  the  ground  segment  (equipment  and  personnel),  the  launch  segment  (equipment  and 
personnel),  and  the  information/  communications  architecture  (user  interface  with  the 
system). 
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20.2.1  Spacecraft  Architecture 


Implementation  of  the  small  tactical  satellite  design  (Tacsat)  should  take  into 
account  the  fact  that  the  “baseline”  design  is  generally  “over  powered”  (i.e.,  the  baseline 
design  provides  too  much  average  and  peak  power  levels  required  for  operation  of  most 
payloads).  With  this  consideration  in  mind,  application  of  an  alternative  design 
architecture  (other  than  the  “one  size  fits  all”  or  “baseline”  architecture)  becomes  desirable 
for  optimization  of  the  bus  to  the  wide  variety  of  mission  modules,  the  majority  of  which 
do  not  require  an  average  power  of  more  than  400  watts  or  a  peak  power  of  over  800 
watts.  The  payloads  which  may  require  these  high  average  and  peak  power  loads  are  those 
of  the  active  type  (LASERs  and  SARs),  whereas  passive  sensors  rarely  require  more  than 
100  watts  of  power  (peak  —  during  a  sensing  pass).  The  optimization  payoff  can  be 
measured  in  these  cases  with  more  available  volume  on  the  bus  (for  other  equipment)  and 
less  spacecraft  bus  mass  (increasing  available  mass  for  the  mission  module,  or  allowing  a 
different  orbit  configuration  —  including  a  higher  initial  altitude). 

Options  to  the  spacecraft  designer  include  either  staying  with  the  baseline  design 
for  all  applications,  standardizing  the  structure  and  modularizing  the  power  systems,  or 
designing  slightly  different  buses  for  either  active  or  passive  sensor  mission  modules  (a 
“family”  of  tactical  buses).  Given  the  non-generic  nature  of  its  design,  a  “specialist”  or 
“microsat  “  architecture,  in  which  the  bus  is  fully  optimized  to  a  particular  mission  module 
type,  falls  outside  the  solution  space,  which  has  evolved  since  Phase  I  of  this  study.  A 
similar  non-player  for  the  implementation  of  the  MEDTAC,  but  on  the  opposite  of  the 
specialist  architecture,  is  the  original  “amoeba”  architecture,  which  would  be  too  generic  a 
concept.  It  would  be  unnecessary  to  have  a  fully  modular  bus  design  in  the  case  of  a 
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tactical  satellite  —  the  modularity  would  evolve  into  a  standard  type,  defeating  the  original 
purpose  of  adaptability.  Adaptability  within  the  scope  of  tactical  space  applications  is 
desirable,  however.  All  of  these  options  will  meet  the  needs  of  the  tactical  space  user  and 
planner. 

Tradeoffs  involved  with  the  decision  to  use  one  particular  architecture  over  the 
others  include  the  cost  involved  with  the  development  of  “modular”  battery  assemblies  and 
solar  arrays;  development  and  construction  cost  savings  reahzed  by  having  no  modularity 
(i.e.,  sticking  with  the  baseline  design),  the  further  development  costs  of  additional  bus 
designs  (albeit  very  similar  buses  with  the  exact  same  components  in  most  cases);  and 
operational  effectiveness  considerations  (e.g.,  time  required  for  integration  of  the  mission 
module,  reliability  issues  with  modular  components,  changing  needs/adaptability). 

Another  consideration  when  deciding  upon  the  particular  satellite  architecture  will 
be  the  benefit  of  having  small,  capable  platforms  ready  to  support  specific  experimental 
payloads,  technology  demonstrations,  or  other  (presently  undetermined)  mission  modules 
(i.e.,  which  approach  will  be  more  adaptable  for  future  missions  beyond  the  currently 
modeled  types?).  This  consideration  becomes  significant  if  this  capability  for  adaptation  is 
desirable  to  the  user  and  planner,  as  well  as  other  potential  DOD  users  outside  the  tactical 
space  community  who  may  have  a  need  for  a  “ride”  into  space  for  one  or  more  of  their 
payloads. 

Roughly  estimating  the  effectiveness  of  the  architectures,  previous  data  (from  the 
first  evaluation  of  the  bus  architectures  ~  see  Volume  11,  Phase  1,  System  Evaluation) 
indicate  that  either  the  multiple  bus  architecture  (‘Tamily”)  or  the  modular  bus  architecture 
(an  infusion  of  aspects  of  the  original  “amoeba”  satellite  design  to  the  baseline  design) 
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would  be  the  optimal  choice.  The  “family”  architecture  would  include  two  standard  buses. 
The  first  bus,  designed  with  a  lower-power  EPS,  would  be  designated  to  carry  the  passive 
sensor  mission  modules.  The  second,  with  the  standard  MIDTAC  power  capability, 
would  carry  the  active  sensor  mission  modules.  The  MIDTAC  bus,  evaluated  as  the  best 
bus  design  among  the  standard  bus  alternatives,  includes  battery  assemblies  and  solar 
arrays  located  in  easy-access  positions,  so  a  modular  design  for  the  battery  and  solar  array 
interfaces  (for  varying  sizes  of  either)  is  also  a  feasible  option.  This  single  subsystem 
(EPS)  and  these  two  primary  components  (solar  arrays  and  batteries)  constitute  the 
modular  design  points  required  to  (as  a  first-order  estimate)  optimize  the  MIDTAC  bus 
for  multiple  space  roles  while  using  the  same  exact  design;  therefore,  the  tradeoff  for  these 
(family  or  modular)  architectures  becomes  the  cost  of  making  the  components  and  their 
interfaces  modular  or  “hardwiring”  the  two  family  buses. 

Given  the  fact  that  the  solar  arrays  for  MIDTAC  are  already  q  modular  design 
tailorable  to  specific  needs,  and  the  fact  that  batteries  already  come  in  varying  sizes  for 
differing  capacity  requirements,  the  modular  option  should  be  the  architecture  chosen  for 
initial  implementation  of  the  Modsat.  Although  actual  operational  configurations  (stored 
and  ready  for  use)  for  the  Modsat  will  probably  mimic  the  ‘Tamily”  architecture  by 
including  “pre-integrated”  buses  already  tailored  for  either  the  low-power  or  high-power 
mission  modules  (possibly  already  integrated  with  the  some  mission  modules,  as  well),  the 
modular  design  of  the  Modsat  provides  ultimate  reconfigurability  to  suit  changing  needs. 

20.2.2  Launch  Segment 

A  small  air-launched  system  provides  maximum  flexibility  for  the  choice  of  initial 
orbit  for  small  tactical  spacecraft,  because  of  the  fact  that  any  launch  azimuth  may  be 
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chosen.  This  capability  also  minimizes  the  time  to  reach  a  chosen  target  (i.e.,  the  direct 
approach  will  be  the  fastest).  The  Pegasus  air  launched  booster  currently  represents  the 
only  launcher  in  this  category.  The  Taurus  booster,  while  not  air  launched,  is  more 
powerful  and  was  developed  specifically  for  rapid  deployment,  integration,  and  launch 
from  unimproved  areas,  making  it  also  a  good  choice  for  the  launch  segment. 

The  force  structure  recommended  for  employment  of  small  tactical  satellite 
designs  consists  of  elements  from  the  30th,  45th,  and  50th  Space  Wings  (30th,  45th,  and 
50th  SW)  working  in  concert.  The  1st  Tactical  Space  Launch  Squadron  (1st  TSLS), 
based  at  Vandenberg  AFB,  CA  (30th  SW)  would  be  responsible  for  westward  (retrograde 
and  Sun-synchronous)  launches  over  the  Pacific  Ocean  .  Similarly  the  2nd  TSLS  (45th 
SW,  Patrick  AFB,  FL)would  be  responsible  for  flights  east,  over  the  Atlantic.  The  19th 
Space  Operations  Squadron  (19th  SOPS),  based  at  Falcon  AFB,  CO  (50th  SW)  would 
have  responsibility  for  Modsat  launch  and  early  orbit  support,  Modsat  conunand  and 
control.  Tactical  Network  (TacNet)  maintenance  and  support,  and  manning  and  operation 
of  the  Consolidated  Tactical  Space  Control  Center  (CTSSC  —  see  below)  for  in-theatre 
operations  support.  Under  the  direction  of  a  Launch  Director,  each  of  the  Tactical  Space 
Launch  Squadrons  would  operate  B-52  or  other  (Pegasus)  carrier  aircraft.  In  addition,  a 
spacecraft-to-mission  module  integration  (SMI)  crew,  a  spacecraft-to-launcher  integration 
(SLI)  crew,  a  loading  crew,  a  flight  and  launch  crew,  an  analysis  crew  and  a  launch 
(command  and  control)  crew  (under  the  direction  of  an  Operations  Director  at  the  19th 
SOPS  and  possibly  deployed  to  a  mobile  or  in-theatre  site),  would  accomplish  the 
integration,  loading,  flight  (to  launch  location  over  either  ocean),  launch,  and  early  orbit 
support  for  the  Modsat  mission. 
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Tactical  Space  Launch  (East  Range/Atlantic) 


Figure  20-1:  Proposed  Organizational  Structure  for  Tactical  Spacelift 

(Eastern  Range/ Atlantic) 

The  environment  for  the  design  study  also  assumes  that  a  ready  supply  of 
launchers,  satellite  buses,  and  mission  modules  is  on  hand  for  both  rapid  response 
situations  and  space  asset  replenishment.  Along  with  the  supplies  of  hardware,  other 
assumptions  include  ample  logistics  equipment  (transports,  “clean”  environments, 
maintenance  equipment,  special  tools,  etc.),  maintenance  personnel,  and  storage  facilities. 
Specific  personnel  for  each  crew  include  enlisted-grade  crew  members  and 
technicians/specialists  led  by  officer-grade  flight  commanders  and  deputies  (doubling  as 
bus,  mission  module,  and  launch  vehicle  experts  for  their  respective  crews),  and  civilian 
engineering  and  analysis  personnel  (in-depth  engineering-intensive  positions  should  be 
made  civilian  contractor  or  GS  billets  to  retain  “corporate  knowledge”  on  the  systems). 
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Tactical  Space  Launch  (West  Range/Pacific) 


Figure  20-2:  Proposed  Organizational  Structure  for  Tactical  Spacelift 

(Western  Range/Pacific) 

20.2.3  Ground  Segment  and  Information/Communications  Architecture 

The  main  ground  segment  for  the  small  tactical  satellite  should  be  an  X,  Ka,  or  Ku 
band  receiving  station,  perhaps  similar  to  the  Air  Force’s  ‘"Eagle  Vision”  mobile,  in-theatre 
ground  station,  which  receives  mission  data  directly  from  both  LANDSAT  and  SPOT 
satellites,  processes  the  imagery,  and  overlays  the  high-resolution  visible-region  imagery  of 
SPOT  with  the  multispectral  imagery  of  LANDSAT.  Multispectral  imagery  products 
from  Eagle  Vision  have  received  rave  reviews  from  operational  and  theatre  commanders 
(Veseley,  1996).  Initial  operations  testing  and/or  proof  of  concept  testing  (for  the  new 
tactical  satellites)  could  be  set  up  to  utilize  current  Eagle  Vision  equipment. 

This  central  receiving,  processing,  and  distribution  station,  known  as  the 
Consolidated  Tactical  Space  Control  Center  (CTSCC)  would  be  manned  and  operated  by 
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crews  from  the  19th  SOPS  (50th  SW)  and  would  also  incorporate  an  S  band 
(SGLS/AFSCN  compatible)  commanding  capability  for  spacecraft  specific  commanding. 
CTSSC  terminal  stations  (including  a  permanent  CTSSC  at  Falcon  AFB,  CO)  would  be 
deployed  at  several  positions  on  the  Earth  to  ensure  full  support  for  any  and  every  theatre 
of  operations.  The  CTSSC  would  be  the  centerpiece  for  a  tactical  space  information 
network  into  which  tactical  users  would  input  requests  and  receive  information  products. 
User  requests/data  updates  would  be  transmitted  via  wireless  ethemet  protocols  (adapted 
from  currently  existing  internet  protocols)  carried  through  either  MBLSTAR  MDR, 
Teledesic,  Iridium,  or  a  similar  high  data  rate,  global  communications  system. 

The  process  would  be  as  follows: 

1)  User  signs  on,  and  requests  are  encrypted  and  transmitted  from  a  laptop  or 
similar  small  computer  in  the  field  or  from  the  cockpit. 

2)  Requests  are  received,  authenticated,  and  prioritized  (set  by  the  Theatre  or 
Operational  Commander)  by  CTSCC  server. 

3)  CTSCC  server  queries  (via  intelligent  agents)  the  types  and  availabilities  of 
appropriate  TACSATs  (based  on  the  type(s)  of  information  requested  by  the  user)  as  well 
as  orbit  predictions  for  those  required  assets  which  are  available. 

4)  The  server  calculates  time  over  target,  time  to  receive  mission  data,  time  to 
process,  filter,  and  package,  and  time  to  transmit  requested  information  to  the  user. 

5)  If  the  requested  information  is  available,  the  CTSSC  server  replies  with  the 
product;  if  not  available,  the  CTSSC  server  replies  with  an  estimated  time  of  arrival  (ETA) 
for  the  product,  based  on  its  calculations  in  4). 
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These  tasks  and  the  artificially  intelligent  systems  and  software  required  to 
accomplish  them  are  possible  with  current  computer  and  software  technology  and  may  be 
made  functionally  “modular”  (in  both  hardware  and  software  design)  to  ensure  future 
upgrade  capability.  To  make  this  system  work  well  for  an  easily  estimable  “many”  users, 
the  communications  systems  employed  and/or  utilized  will  have  to  support  the  necessary 
bandwidth  to  successfully  support  the  tactical  user  in  a  timely  fashion;  otherwise,  the 
CTSCC’s  tactical  support  capability  will  be  degraded.  Centralizing  the  processing  power 
of  this  tactical  space  information  system  in  the  CTSSC  (as  opposed  to  performing  the 
data-to-information  processing  on  the  satellites)  allows  more  processing  power  to  be 
utilized,  allows  easy  upgrades  to  software,  allows  simpler  troubleshooting  of  software, 
retains  the  satellites’  simplicity  --  both  from  the  hardware  and  the  software  standpoints, 
retains  central  control  authority  for  information  dissemination,  promotes  optimal  tasking 
of  resources  (again,  due  to  centralized  control  and  prioritization),  simplifies 
communications  to  and  from  the  satellites  (multiple  channels  are  unnecessary),  and  allows 
future  upgrades  to  the  overall  architecture  to  perhaps  “evolve”  into  a  system  which 
incorporates  more  “on  board”  processing  and  direct  downlinking  to  users.  Having  the 
information  processed  by  the  ground  segment  is  the  simpler,  more  powerful  choice  for 
current  technology. 
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Tactical  Space  Launch  (Command  and  Control) 


Figure  20-3:  Proposed  Organizational  Structure  for  Tactical  Spacelift 

(Command  and  Control) 

An  alternative  to  the  (assumed  baseline)  ground-based  CTSSC  would  be  a 
dedicated  command  and  control  aircraft,  or  the  CTSCC  could  be  palletized  and  flown 
aboard  a  C-17  or  C-5,  further  enhancing  its  mobility. 
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21.  Future  Technologies  and  Continuing  Investigations 


The  preliminary  design  for  a  small  tactical  spacecraft  bus  provides  a  solid 
foundation  for  further  investigations  as  well  as  continued  expansion  of  the  Modsat 
computer  design  model.  Design  efforts  generated  a  tremendous  amount  of  information  in 
addition  to  producing  the  Modsat  computer-based  design  tool  and  a  design  for  a  standard, 
tactically  applicable  satellite  bus.  Much  of  this  information  was  not  included  within  the 
formal  system  process  either  due  to  the  planning  horizon  for  the  proposed  design  (five 
years)  or  because  of  the  “nonessential”  nature  of  much  of  the  information  (to  the  design). 
These  topics  nonetheless  sparked  many  discussions  during  meetings  and  comprise  an 
interesting  set  of  ideas  and  technologies  on  which  to  base  a  possible  future  design  study 
(or  design  studies).  The  design  process  also  generated  several  concepts  for  future 
scientific  research,  operational  analysis,  and  system  design. 

21.1  Modsat  Computer  Model  Enhancements 

The  Modsat  computer  model,  which  was  developed  to  aid  in  the  design  and 
evaluation  of  small  tactical  satellite  designs,  provides  a  foundation  for  further 
enhancements,  additions,  refinements,  and  detail.  Modsat’s  coding,  though  large  in  scope, 
is  rather  simple  in  style,  and  it  is  thoroughly  documented  internally.  Future  additions  or 
modifications  to  the  code  may  include: 

•  more  integration  of  orbit  analysis  features 

•  additional  mission  module  configurations  and/or  types 

•  additional  cost  models 
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•  more  detailed  component  or  subsystem  modeling 

•  larger  libraries  of  selectable  components 

•  fijture  technology  modeling 

•  more  in-depth  launch  vehicle  modeling  and/or  design 

•  more  detailed  interface  modeling 

Detailed  discussion  of  the  individual  sections  and  functions  (background,  scope, 
functionality,  limitation(s),  and  future  feature  suggestions)  of  the  Modsat  computer  model 
can  be  found  in  Volume  III  in  the  Modeling  section. 

21.2  Constellation  Design 

Multiple  satellites,  carrying  active  sensors,  may  in  the  future  be  employed  in 
concert  as  an  “array”  of  sensors.  The  operational  challenge  of  such  a  constellation  can  be 
solved  either  by  maintaining  relative  satellite  positions  and  attitudes  to  within  close 
tolerances  (within  a  few  millimeters),  or  by  maintaining  extremely  accurate  position  and 
orientation  knowledge  (to  within  a  few  millimeters).  The  second  solution  is  the  more 
feasible  of  the  two,  because  satellites  equipped  with  multiple  GPS  receivers  can  produce 
these  knowledge  products  to  within  the  accuracy  necessary  (NASA,  1995:  sec.7,  p.3), 
and  with  this  knowledge  ground-based  computer  processing  can  correct  for  discrepancies 
in  received  signals  (between  spacecraft).  A  constellation  of  this  type  would  have  the 
potential  of  creating  an  extremely  large  synthesized  aperture;  however,  the  processing 
power  required  for  a  constellation  of  more  than  two  or  three  satellites  would  no  doubt  be 
tremendous  and  possibly  prohibitive  with  current  capabilities. 
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Further  analysis  may  be  performed  regarding  the  types  of  orbits  employed  for 
tactical  satellites.  The  primary  orbit  chosen  as  the  baseline  for  this  study  was  a  Sun- 
synchronous  orbit  at  an  altitude  of  350  kilometers.  This  orbit  type  has  definite  advantages 
for  remote  sensing  and  Earth  resources  missions;  however,  other  orbits  exist  which  may 
provide  greater  utility  for  specific  missions.  The  highly  eccentric  Molniya  orbits  provide 
long  dwell  time,  but  at  a  geosynchronous  altitude  during  that  dwell  time;  this  orbit  type 
may  be  useful  for  tactically-applied  communications  satellites  designed  for  short  mission 
durations.  “Walker”  orbit  parameters  (Wertz,  1992:  189-192)  provide  a  useful  method 
for  construction  of  constellations  with  specific  coverage  goals  in  mind.  One  example  is 
that  of  multiple  satellites  being  “staggered”  in  one  or  more  specific  orbital  planes  such 
that,  as  one  satellite  “sets  “  on  a  target,  the  next  satellite  in  line  comes  into  view. 
Constellation  design  and  optimization  is  a  complex  art.  Space  planners  and  designers  may 
wish  to  examine  the  advantages  and  disadvantages  of  the  coverages,  dwell  times,  revisit 
times,  and  environmental  stresses  associated  with  various  orbit  types. 

21.3  Logistics  and  Operations 

There  are  logistical  challenges  involved  with  the  transport,  storage,  and 
maintenance  of  a  (large)  supply  of  not  only  tactical  satellite  buses,  but  also  mission 
modules  (of  multiple  types),  small  launch  vehicles,  and  support  equipment  (and  support 
aircraft  in  the  case  of  air-launched  spacelifl).  Another  possible  (albeit  novel)  logistical 
and/or  operational  strategy  study  would  be  to  investigate  possible  ways  of  recovering  the 
satellites  -  either  by  retrieval  or  reentry  —  and  gauge  their  feasibility  and  utility  in  a 
tactical  environment  constrained  by  costs  and  the  increasing  desire  to  reuse  hardware. 
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Further  analysis  may  be  performed  on  the  actual  missions  and/or  applications  for 
the  tactical  satellite,  not  only  on  the  sensing  and  support  (of  terrestrial  forces)  aspect  of 
space  based  platforms,  but  also  on  the  possible  force  application  roles  of  such  platforms. 

The  air-launched  ICBM  test  program  of  the  1970s  and  the  current  “ALT-Air” 
program  sponsored  by  the  Ballistic  Missile  Defense  Organization  (BMDO)  have 
demonstrated  the  feasibility  of  a  carrier  aircraft-based,  palletized  launch  scheme.  In  this 
scheme,  a  launch  vehicle  is  transported  inside  the  carrier  aircraft,  deployed  off"  of  an  aft- 
ejected,  parachute-assisted  pallet  with  a  stabilized  drogue  chute,  and  ignited.  This  launch 
scheme  could  be  applied  to  a  new  launch  system  specifically  designed  for  this  purpose. 
Investigations  could  include  adaptation  of  an  existing  system  to  this  scheme  (like  the 
ICBM  tests  of  twenty  years  ago).  This  transport  environment  has  the  potential  of 
providing  a  much  more  benign  environment  (vibrational  and  thermal)  for  the  launcher  and 
spacecraft  payload,  as  well  as  possibly  supporting  a  “clean”  environment  (e.g.,  a  “clean 
tent”  such  as  used  by  the  Pegasus)  inside  the  aircraft  itself  during  transport  --  due  to  the 
fact  that  the  interior  of  the  aircraft  is  environmentally  controllable.  Additionally,  regular 
loading  crews  would  need  no  special  training  for  handling  the  rocket  pallet,  since  the  pallet 
would  be  the  same  as  any  other  pallet  fitted  for  that  particular  aircraft. 

21.4  Mission  Modules 

This  design  study  focuses  specific  design  determination  efforts  upon  only  the 
satellite  bus;  however,  due  to  the  particular  design  paradigm,  the  primary  design  standards 
imposed  upon  the  mission  module  designer  may  be  enumerated.  Though  the  standard 
small  tactical  spacecraft  bus  will  provide  support  for  the  mission  modules,  mission  module 
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designers  will  be  required  to  design  “to  the  bus”,  as  opposed  to  the  bus  being  built  for  the 
specific  payload  equipment.  Analogous  to  the  interface  requirements  to  which  underwing 
stores  on  a  fighter  must  be  designed,  the  mission  modules  must  conform  to  certain 
electrical,  mechanical,  data  protocol,  telemetric,  and  software  interfaces  incorporated  into 
the  bus  design.  Many  of  the  specifications  for  these  interfaces  will  be  provided  by  the 
SPIG  (see  Tradeoffs). 

The  candidate  bus  designs  were  judged  upon  the  amount  of  launch  volume  and 
launch  mass  which  they  reserved  within  the  Pegasus  payload  fairing  for  the  mission 
module.  The  implemented  satellite  bus  design  will  provide  both  a  launch  volume 
“envelope”  and  a  launch  mass  budget  within  both  of  which  the  volume  and  mass  of  the 
mission  module  must  remain.  Another  primaiy  performance  design  point  for  the  mission 
module  designer  will  be  the  amount  of  power  available  for  proper  operation  of  the  mission 
module. 

The  mission  module  designers  and  builders  will  be  expected  to  provide  any 
software  and/or  satellite  operating  system  patches  or  extensions  specific  to  the  mission 
being  supported  by  a  particular  mission  module.  A  software  extension  may,  for  example, 
include  an  update  to  the  spacecraft’s  attitude  control  logic,  specifying  attitude  tolerances 
(pointing  accuracy,  attitude  knowledge,  etc.).  Depending  on  the  specific  mission  for 
which  the  spacecraft  and  mission  module  will  be  employed,  several  different  software 
extensions  may  be  applicable  within  a  single  type  of  mission  module  (i.e.,  the  software 
provided  with  a  mission  module  will  be  expected  to  tailor  the  mission  module  to  a  specific 
mission).  This  requirement  should  provide  space  planners  ample  flexibility  in  the 
application  of  a  single  type  of  mission  module.  This  flexibility  will  also  provide  planners 
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with  the  capability  to  update  mission  parameters  as  theatrical  situation  and  requirements 
change. 

Thermal  protection  and  radiation  protection  must  also  be  incorporated  into  mission 
module  design;  the  bus  does  not  provide  protection  to  the  mission  module  from  these  two 
elements.  These  protective  measures  may  include  blankets,  coatings,  radiation  hardening, 
cryogenics,  etc.  The  methods  employed  for  a  given  mission  module  will  vary  depending 
on  the  type  of  equipment  employed,  and  will  be  left  completely  to  the  mission  module 
designers. 

One  final  capability  which  all  mission  module  types  must  incorporate  is  the 
capabihty  for  a  “quick  startup.”  The  tactical  space  planner  must  have  the  means  to  place  a 
mission  module  into  a  desired  position  and  begin  delivery  of  mission  data  as  soon  as 
possible.  This  is  a  very  nonspecific  requirement,  due  to  the  different  functional 
complexities  associated  with  different  types  of  mission  modules,  and  one  which  will 
probably  be  determinable  only  after  on-orbit  experience  has  been  gained  with  the  new 
systems.  Certainly  the  deployment  of  solar  arrays,  calibration  of  sensing  equipment, 
calibration  of  attitude  sensors,  and  initial  power  system  loading  procedures  will  preclude  a 
mission  module  from  performing  its  mission  immediately  after  launch.  But  robust 
calibration  and  testing  by  integration  crews  before  launch  (or  similar  “streamlining”  of 
initial  checkout  procedures),  in  conjunction  with  experience,  may  be  able  to  minimize  the 
commanding  and  testing  time  necessary  to  fully  prepare  the  satellite.  In  this  respect, 
minimizing  this  delay  for  initial  satellite  checkout  is  a  design  goal,  not  only  for  the  mission 
modules  but  also  for  the  satellite  bus.  This  design  goal  is  captured  within  the  value  system 
design  by  the  objective  “minimize  preparation  time  to  launch”;  all  activities  leading  up  to 
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full  operational  capability  are  considered  to  be  the  “launch”  phase.  Since  this  is  an 
objective  to  be  addressed  in  the  design  of  the  bus,  the  mission  module  designers  should 
also  address  this  objective  within  their  designs. 

Table  21-1  summarizes  the  generally  specified  requirements  for  the  design  of  the 
various  mission  modules. 


Table  21-1:  Mission  Module  Design  Requirements 


Design  Consideration 

Mission  Module  Design  Requirement 

Mission  Scope 

single-sensor  type;  narrow  mission  specification 

Mission  Mass 

under  120  kg 

Mission  Power 

average  under  320  W 
peak  under  820  W 

Mission  Volume 

under  0.6  m 

High  Data  Rate  Downlink 

must  be  integral  if  greater  than  SGLS  rate  is  desired 

Data  Storage  Capacity 

must  be  integral  if  greater  than  2Gbytes  is  desired 
(unless  storage  is  modular) 

Mechanical  Interface 

conform  to  SPIG 

Electrical  Interface 

28  V  regulated  bus  standard;  conform  to  SPIG 

Telemetry/Software  Interface 

compatibility  with  bus  standard  formatting;  specialized 
mission  software  extensions  (to  SOS)  must  be  integral 

Thermal  Environment 

isolation  from  bus;  specialized  mission  equipment 
integral 

Design  Focus 

tactical;  minimize  testing  time;  minimize  warmup  time 

The  mission  modules  modeled  in  the  Modsat  computer  model  are  necessarily 
“generic”  in  nature  to  provide  both  flexibility  in  design  evaluation  and  a  foundation  on 
which  more  specific  types  may  be  modeled  in  both  the  current  version  and  in  future 
versions. 

Future  operational  analysis  may  focus  on  optimizing  the  functionality  of  different 
types  of  mission  modules  and  putting  together  the  most  tactically  useful,  easily  storable. 
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quickly  integratable,  and  technically  feasible  combination  of  mission  modules  for  tactical 
space  missions. 

A  specific  mission  module  for  performance  of  a  “LASER  designator  from  space” 
role  was  not  specifically  addressed  by  the  system  design  study,  due  to  the  number  and 
variability  of  the  many  factors  involved  in  the  mission  analysis  for  such  a  mission  module, 
as  well  as  the  “experimental”  nature  of  any  such  mission  module  if  constructed  with 
current  technology.  A  mission  module  of  this  type  may  be  roughly  modeled,  however, 
with  the  LASER/LID AR  mission  module  tools  incorporated  in  the  Modsat  computer 
model.  A  future  trade  study  on  the  design  of  such  a  mission  module  would  require 
analysis  of  1)  illumination  efficiency,  power,  and  wavelength(s);  2)  target 
reflectivity/signature  in  the  given  wavelength(s);  3)  detector  positioning  (azimuth, 
elevation,  and  altitude),  sensitivity  in  the  given  wavelength(s),  field  of  view,  signal  to  noise 
ratio,  and  velocity;  and  4)  possible  adversarial  countermeasures  and  spoofing.  Finally, 
sizing  of  the  mission  module’s  volume,  mass,  and  power  requirements  may  or  may  not 
make  this  application  feasible  for  a  small  satellite  application.  Of  course,  a  primary  goal  of 
this  type  of  research  would  be  the  determination  of  “payoffs”  in  costs,  manpower, 
equipment,  capability,  and  responsiveness  that  this  type  of  system  may  or  may  not 
achieve. 

A  similarly  experimental  application  (and  as  worthy  or  more  worthy  of  fiirther 
investigation)  being  developed  for  LASERs  is  that  of  extremely  high  data  rate 
communications  systems.  Many  of  the  tradeoff  factors  and  design  considerations  involved 
in  the  design  of  a  LASER  designation  system  are  applicable  to  the  design  of  a  LASER- 
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based  communications  system  (i.e.,  power,  sensitivity,  positioning,  signal  to  noise  ratio, 
field  of  view,  and ,  of  course,  atmospheric  attenuation). 


21.5  Small  Satellite  Technologies  “On  the  Horizon” 

Many  novel  and  exciting  (as  well  as  very  technically  challenging)  technologies 
promise  to  change  the  face  of  satellite  design  in  the  not  so  distant  future.  All  of  these 
technologies  are  expected  to  be  developed  within  the  next  ten  years. 

Flywheel  Technology  —  Flywheels  provide  power  and  momentum  storage  through  the 
utilization  of  kinetic  energy  storage.  These  structures  represent  potentially  lighter  weight 
and  higher  capacity  than  chemical-based  batteries,  with  the  added  functionality  of  naturally 
stabilizing  a  spacecraft  in  (as  do  traditional  momentum  wheels).  This  “functional  density” 
(in  which  one  component  performs  more  than  one  function)  is  a  popular  theme  for  small 
satellite  design,  and  is  already  evident  in  most  designs  for  spacecraft  CPUs,  as 
multifunctional  microprocessors  are  becoming  the  norm  for  small  satellites  (Hively,  1996). 

Lithium-Ion  Batteries  --  These  batteries  provide  vastly  higher  capacity  than  traditional 
and  current  technology  chemical  batteries  (see  Vol  II,  Tradeoffs,  Electrical  Power 
Subsystem). 

Inflatable  Structures  —  This  technology  will  allow  smaller  spacecraft  buses  to  support 
much  larger,  more  capable  active  sensors,  such  as  those  required  for  synthetic  aperture 
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RADAR.  Current  efforts  are  underway  at  NASA  to  produce  electronically  steerable, 
high-resolution  RADARs  for  launch  on  small  vehicles,  but  inflatable  structure  technology 
would  significantly  reduce  payload  mass  and  required  payload  fairing  volume  (scaling 
down  required  volume  from  “cubic  feet”  to  volumes  on  the  order  of  “cubic  inches”), 
thereby  fi'eeing  up  space  on  the  booster  for  other  experiments  (on  the  spacecrafl;)  or  other 
vehicles  (within  the  fairing)  (NASA,  1995). 

Global  Positioning  System  (GPS)  Applications  —  GPS  promises  to  provide  much  better 
accuracy  and  more  timely  and  autonomous  orbital  position  prediction  and  tracking  than 
current  methods  of  ground  tracking.  Utilization  of  GPS  will  free  up  much  of  the 
overtaxed  Air  Force  Satellite  Control  Network  (AFSCN)  from  mundane  “tracking” 
supports  for  the  new  vehicles  equipped  with  GPS  receivers.  Experiments  in  the  future  will 
also  include  single  vehicles  equipped  with  multiple  receivers,  testing  GPS  capability  to 
determine  spacecraft  attitude.  If  this  application  proves  functional,  it  will  relieve  much  of 
the  attitude  control  system  requirements  for  attitude  knowledge  sensors,  thereby  further 
reducing  spacecraft  mass. 

“Toroidal”  Propellant  Tank  -  This  propellant  tank  design  was  borne  out  of  system 
synthesis  efforts  as  a  theoretically  more  efficient  propellant  tank  packaging  scheme, 
optimizing  available  volume  within  a  spacecraft. 

Fourier  Transform  Hyperspectral  Imaging  —  This  imaging  package  under  investigation 
at  Phillips  Lab  represents  a  new  paradigm  in  multispectral  imaging  —  spectral  resolution 
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approaching  that  of  gas  chromatography  and/or  spectrometers  (i.e.,  evolution  toward  a 
“continuous  spectral  imaging  system”  paradigm)  through  the  usage  of  Fourier  Transform 
systems  for  spectral  separation.  Improved  spectral  resolution,  lighter  instrument  weight, 
and  more  efficient  transmission  (than  the  current  “best”  method  of  dispersion  gratings)  is 
achieved  through  Fourier  Transform  separation  (Hagan,  1996;Otten  and  others,  1995), 

Pulsed  plasma  thrusters  ~  These  and  other  low-thrust,  high  specific  impulse,  non 
chemical  propulsion  systems  will  provide  lower  thrust,  but  more  total  delta-velocity 
capability  (per  unit  mass)  over  the  life  of  the  satellite  than  chemical  thrusters  (Hagan, 
1996).  Experiments  utilizing  PPTs  are  planned  for  the  Phillips  Lab’s  MightySat  program. 

Ka-Band  Transmitter  Experiment  -  Another  experimental  payload  project  for  the 
Phillips  Lab  MightySat  program,  this  phased  array  communications  package  will  provide 
testing  and  validation  of  technologies  expected  to  reduce  the  mass,  moving  parts,  and 
spacecraft  attitude  adjustments  required  to  track  a  signal  from  a  communications  ground 
station.  It  will  also  study  high  data  rate  modulation  techniques. 

Small  liquid-fueled  booster  —  Solid  rocket  motors  (SRMs),  while  inexpensive  and  easily 
adaptable  to  small  launch  systems,  are  heavy,  toxic,  fragile,  less  flexible,  and  less  reliable 
(in  general)  than  liquid  rocket-based  launch  systems.  Phillips  Lab  and  other  research 
organizations  (as  well  as  some  sectors  in  industry)  are  developing  prototypes  of  a 
simplified  “blow  down”  pressurized  liquid-fueled  rocket  for  use  as  a  small  launch  system 
(Warner,  1996;  Worden,  1996).  This  system  incorporates  propellant,  oxidizer,  and  an 
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inert  pressurant  (helium)  to  inject  the  propellant  and  oxidizer  into  the  combustion 
chamber.  This  system  can  be  built  with  few  or  no  moving  parts,  and,  by  virtue  of  being 
“throttleable”  the  system’s  performance  can  be  fine-tuned  and/or  trimmed  during  flight  (as 
opposed  to  a  SRM,  which  may  be  vectorable,  but  not  dynamically  thrust-variable  while  in¬ 
flight),  thereby  increasing  initial  orbit  accuracy.  These  types  of  simple,  small  rockets  could 
eventually  replace  SRMs  in  most  applications  (e.g.,  as  an  air-launched  system). 
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22.  Conclusions 


Although  the  individual  products  and  ideas  generated  throughout  this  study  may 
be  individually  worthy  of  merit,  the  three  important  results  of  this  study  ftilly  characterize 
the  synergism  of  the  effort.  The  utilization  of  an  adaptable  (i.e.,  specific  to  the  task  at  hand 
and  the  circumstances  of  the  environment)  System  Design  Process  made  all  of  the  effort 
possible  and  productive.  The  generation  of  a  feasible,  value-added,  “clean-sheet” 
MIDTAC  design  for  a  small  tactical  satellite  bus  provides  a  basis  for  further  development 
of  “tactical  space”  or  “TacSpace”  concepts.  The  construction  of  a  generic  and  modular 
(i.e.,  robust,  modifiable,  expandable)  Modsat  Computer  Design  Model,  though  the 
greatest  challenge  of  the  effort,  provides  a  useful,  valuable  design  platform  for  use  by  both 
fixture  researchers  and  students. 

22.1  Modsat  Model 

The  construction  effort  involved  with  the  development  of  a  fiilly  integrated 
computer  design  and  analysis  tool  for  small  satelhtes  comprised  a  systematic  design 
process  in  itself  As  with  the  individual  subsystem  component  choices,  individual 
subsystem  modeling  sections  formed  along  baseline  component  characteristics  determined 
by  the  subsystem  trade  studies.  The  value  system  determined  by  the  team  formed  the 
basis  of  the  analysis  section  of  the  model.  The  Modsat  modeling  software  package 
provides  for  analysis  of  physical  characteristics,  mission  performance,  and  overall  costs. 

The  Modsat  model  provides  a  foundation  for  further  analysis  efforts.  The 
underlying  functions  of  the  software  may  be  modified  or  expanded  according  to  a 
particular  user’s  requirements  and  objectives.  A  vast  array  of  different  sizes,  shapes. 


370 


materials,  and  other  characteristics  may  be  modeled,  based  upon  user  input.  The  initial 
version  of  the  model  provides  estimations  which  may  be  updated  (through  modification  of 
the  underlying  code)  with  evolutions  in  space  technology  or  changes  in  design  philosophy. 
Aside  fi'om  these  more  esoteric  considerations,  the  sofl:ware,  of  course,  may  be  used  for 
the  analysis  of  small  satellite  designs  other  than  those  analyzed  in  this  preliminary  study. 
Using  differently  modeled  components  and  differently  modeled  value  systems,  the  Modsat 
modeling  tool  has  the  capability  to  produce  a  wide  range  of  possible  designs. 

22.2  Design  Concept 

The  MEDTAC  spacecraft  bus  provides  a  generic  design  that  may  be  further 
developed  for  specific  applications  or  more  completely  engineered  for  actual  production. 
The  MIDTAC  bus,  as  a  complete  system,  has  been  designed  to  the  extent  that  feasible  bus 
enhancements  may  be  easily  explored  and  developed.  As  recommended  by  this  system 
study,  the  expected  implementation  of  the  MIDTAC  bus  incorporates  a  modular  power 
generation  system  to  provide  tailoring  of  power  levels  required  by  various  mission 
modules.  The  actual  design  may  also  incorporate  other  modular  and/or  tailorable 
components  or  subsystems. 

The  next  step  in  the  development  of  this  bus  design  should  be  an  engineering  study 
of  the  interfaces  required  to  integrate  all  of  the  individual  satellite  subsystems  and 
components.  While  the  MIDTAC  design  includes  physical  characteristics  and  a  “working 
concept”,  this  design  is  only  the  first  step  in  development  process;  it  comprises  the  results 
of  an  initial  “concept  exploration”  phase  for  a  new  space  system.  Concurrent  engineering 
studies  concerning  manufacturing,  integration,  and  testing  for  the  MIDTAC  design  must 
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also  be  accomplished.  Finally,  mission  modules  must  be  designed  for  flight  testing  and 


operation  on  the  MIDTAC  bus. 

Figure  22-1:  MIDTAC  Bus  and  Vital  Statistics 


Physical  Characteristics/Capabilities: 

Mass:  243  kg 

Available  Power  (average/peak):  319/827  W  (tailorable  to  mission) 

Available  Mission  Mass:  75  kg  (350  km,  sun-synch)/200  kg  (350  km,  28.5  deg) 
Available  Mission  Volume:  0.7855  m^ 

Pointing  Accuracy/Attitude  Knowledge:  0.1  deg/0.05  deg  (nominal) 

Data  Storage:  Modular  2Gbyte  SSDR  (tailorable  to  mission) 

Delta-velocity  Capacity:  300m/s 


Subsystem  Features: 

Mission  Modules:  SPIG  interfaces,  EO,  MSI,  LASER/LID AR,  SAR 

ADCS:  three-axis  stabilized,  reaction  wheels  (4),  star  sensor.  Earth  sensor,  IMU 

Propulsion:  monopropellant  thrusters  (6),  cylindrical  tanks  (4) 

Structural:  octagonal  “cage”  structure,  “3-level”  shelf  system,  SMASH  option 
EPS:  NiH2  batteries,  modular  GaAs  solar  arrays,  decentralized  distribution 
TT&C:  SGLS  compatible,  1024  kbps  nominal  downlink.  Satellite  Operating  System 
(SOS),  TCP/IP  protocol 
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The  MIDTAC  design  ultimately  provides  a  solution  to  one  portion  of  a  much 
greater,  underlying  problem  facing  modem  space  efforts  (military,  scientific,  and 
commercial).  More  responsive,  less  expensive,  and  more  efficient  access  to  space  is  an 
issue  which  requires  new  and  innovative  approaches  to  not  only  spacecraft  design  (the 
focus  of  this  study),  but  also  spacelift,  command  and  control,  and  information  processing 
and  distribution.  In  addition  to  providing  a  tactically  applicable  satellite  bus,  the  MIDTAC 
design  will  provide  the  Air  Force  with  ready-to-fly  space  research  platforms.  The  space 
environment  will  be  more  accessible  to  technology  demonstrations,  developmental 
payloads,  and  other  space  experiments  by  having  these  standard  buses  (with  standard 
mission  interfaces)  readily  available.  The  MIDTAC  design  essentially  provides  to  the  Air 
Force  a  standard  vehicle  —  putting  the  “horse”  before  the  “cart”  —  on  which  it  may  more 
readily  and  effectively  conduct  space  operations  and  technology  development.  MIDTAC 
will  allow  the  Air  Force  to  more  quickly  accumulate  valuable  “spaceflight  time”  and 
experience.  Only  with  increased  “hands  on”  experience  in  spaceflight  and  space 
operations  will  the  Air  Force  fully  evolve  into  its  role  as  a  “Spacepower”.  MIDTAC 
provides  the  means  to  that  end. 

22.3  System  Process  and  Beyond 

The  start  of  the  system  design  began  necessarily  with  a  generalized,  high-level 
treatment  of  the  problem  posed  by  the  CDM;  the  generation  of  a  “clean  sheet”  tactical 
satellite  design  for  use  as  a  “multirole”  satellite,  capable  of  supporting  a  wide  variety  of 
payload  (mission  module)  types.  This  design  should  be  easily  and  inexpensively  produced 
for  the  Air  Force,  smoothly  integrated  by  a  primarily  “blue  suit”  special  weapons  crew. 
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and  quickly  launched  for  either  quick-response  or  asset-replenishment  missions.  Initial 
considerations  involved  the  various  high-level  (nonspecific  components)  design  and 
implementation  approaches  to  this  problem;  further  efforts  evolved  to  focus  eflforts  on 
creating  the  “baseline”  or  “point  design”  with  which  the  original  design  approaches  could 
be  considered  in  combination.  This  combination  of  design  (the  MIDTAC)  and  approach 
(i.e.,  modularized  components)  produced  an  optimal  solution. 

The  (satellite)  functional  division  of  effort,  in  addition  to  the  assignment  of  system 
process  responsibilities  among  team  members,  was  key  to  success.  The  convergence  of 
the  overall  design  and  the  development  of  the  Modsat  modeling  software  required  expert 
knowledge  of  individual  subsystems.  Consideration  of  generic  remote  sensing  mission 
modules  provided  baseline  requirements  for  the  bus  design.  The  system,  reliability,  and 
subsystem  trade  studies  narrowed  the  solution  space  for  the  bus  design  to  a  point  where 
baseline  designs  could  be  generated.  Effective  coordination  of  the  overall  system  design 
effort  required  central  coordination  for  each  of  the  system  process  phases:  problem 
definition,  value  system  design,  system  and  subsystem  design  tradeoffs,  system  synthesis, 
modeling  and  optimization,  decision  making,  and  implementation.  This  approach  not  only 
allowed  the  systematic  construction  of  a  robust  design  and  analysis  tool,  but  also  the 
synthesis  of  seven  fully  integrated,  fully  characterized  designs  which  could  then  be 
thoroughly  analyzed  and  evaluated. 

The  basic  vahdity  and  robustness  of  the  process  may  be  fully  and  objectively 
realized  when  considering  the  role  of  the  CDM.  Other  than  an  initial,  broad  design 
philosophy,  the  CDM  provided  little  input.  Faced  with  this  “ill-posed”  problem,  the  team 
created  a  process  which  allowed  a  “natural”  evolution  of  objectives,  focusing  of  efforts. 
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convergence  of  designs,  and,  most  importantly,  solidification  of  goals.  These  goals 
included  the  construction  of  the  Modsat  model  and  the  development  of  a  “baseline” 
design.  Modification  of  either  the  assumptions  of  the  problem  definition  or  the  value 
system  (based  upon  the  preferences  of  the  CDM)  may  yield  vastly  different  results.  This 
allows  the  adaptability  of  the  process  to  other  space  system  design  projects. 

This  process  is  unique,  innovative,  and  goes  beyond  traditional  system  and  satellite 
design  approaches.  Although  Hall’s  Process  and  the  SMAD  process  were  used  as 
references  and  process  “baselines”,  these  approaches  ultimately  proved  unsuitable,  due  to 
the  unusual  design  paradigm  assumed  by  the  team.  The  “mission  module”  is  a  concept 
wherein  the  payload  equipment  must  be  integrated  to  the  satellite  bus  and  conform  to  bus- 
constrained  design  parameters.  This  is  a  design  paradigm  unpopular  within  the  aerospace 
industry,  and  runs  contrary  to  the  traditional  approaches  to  spacecraft  design  prescribed  by 
the  SMAD  process.  Considering  the  stagnation  of  space  efforts  and  the  lack  of  relief  from 
the  high  cost  and  low  availability  of  space  access,  the  pursuit  of  an  alternative  spacecraft 
design  paradigm  was  reasonable,  if  not  necessary.  The  team  required,  and  ultimately 
developed,  a  process  that  was  less  dependent  upon  mission-derived  design  specifications 
and  allowed  more  design  freedom  to  consider  the  wide  range  of  spacecraft  design 
possibilities. 

Finally,  the  process  is,  unlike  the  SMAD  process,  synergistic  in  approach,  and  it 
epitomizes  the  concept  of  “functional  density,”  wherein  the  process  served  many  purposes 
simultaneously.  The  research  involved  in  the  subsystem  trade  studies  produced  the 
component  data  for  use  in  the  modeling  tool,  narrowed  the  scope  of  subsystem  design 
choices,  and  refined  the  design  objectives  and  value  system.  The  iterative  process  of  the 
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synthesis  of  individual  designs  solidified  design  alternatives  and  also  refined  the  model. 
The  ultimate  results  of  the  development  and  application  of  this  process  resonate  beyond 
the  generation  of  the  MIDTAC  design  and  the  development  of  the  Modsat  model.  The 
results  of  this  study  show  that,  as  a  solution  to  the  “space  access”  problem,  an  alternative 
to  the  current  design  paradigm  (i.e.,  “generic”  versus  “specific”)  is  not  only  feasible  but 
desirable.  This  study,  its  process,  and  its  products  set  the  standards  of  creativity, 
innovativeness,  adaptability,  and  robustness  for  fijture  spacecraft  design  efforts.  The 
Modsat  design  team  has  set  the  bold  example  that  others  will  follow. 
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APPENDIX  A:  CRITERIA  PREFERENCE  IN  THE  DESIGN  OF  A  SMALL, 


STANDARDIZED,  TACTICAL  SATELLITE  BUS 


We  are  conducting  a  systems  study  to  create  a  preliminary  design  concept  for  a  small, 
stamdardized,  tactical  satellite  bus.  You  could  greatly  assist  us  by  filling  out  the 
Preference  Charts  on  the  following  pages.  By  doing  so  you  will  give  us  an  idea  of  the 
relative  priorities  you  place  on  the  criteria  we  have  chosen  to  evaluate  our  solutions.  The 
example  below  explains  how  to  fill  out  a  preference  chart.  Your  experience  and  opinions 
are  highly  valued. 

HOW  TO  FILL  OUT  A  PREFERENCE  CHART 

Fill  in  each  cell  with  one  of  the  following  symbols; 

means  ‘‘much  less  important” 
means  ‘‘less  important” 

=  means  ‘‘equally  important” 

+  means  ‘‘more  important” 

++  means  ‘‘much  more  important” 

For  example,  a  “+”  in  cell  “ij”  means  that  the  criteria  in  row  i  more  important  that  than  the 
criteria  in  column  j 

Note  that  you  only  have  to  fill  in  cells  above  or  below  the  diagonal.  The  cells  on  the  other 
side  of  the  diagonal  are  just  the  inverse  of  the  cells  you  filled  in. 
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EXAMPLE 

Suppose  that  you  established  4  criteria  for  buying  a  car  (1)  minimize  cost,  (2)  maximize 
gas  mileage,  (3)  Appearance,  (4)  Towing  capacity. 


Buying  a 
Car 


Min 

Max  Gas 

Towing 

Cost 

Mileage 

Appearance 

Capacity 

Min  Cost 

+ 

++ 

+ 

Max  Gas 
Mileage 

- 

+ 

— 

Appearance 

- 

- 

Towing 

Capacity 

- 

+ 

This  table  states  that  the  individual  who  filled  out  this  chart  feels: 
Minimizing  Cost  is  more  important  than  Maximizing  Gas  Mileage 
Minimizing  Cost  is  much  more  important  than  Appearance 
Minimizing  Cost  is  more  important  than  Towing  Capacity 
Maximizing  Gas  mileage  is  more  important  that  Appearance 
Maximizing  Gas  mileage  is  equally  important  as  Towing  Capacity 
Appearance  is  less  important  than  Towing  Capacity 
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CRITERIA  DESCRIPTIONS 


The  main  objective,  which  encompasses  all  lower  level  objectives,  is: 

“  DEVELOP  THE  BEST  STANDARDIZED  BUS  FOR  SMALL  TACTICAL 
SATELLITES  ”, 

The  key  words  are  defined  as  follows; 

BUS:  The  bus  is  that  collection  of  satellite  components  whose  functions  are  generally 
common  to  all  satellites.  The  bus  provides  all  the  housekeeping  and  support  functions 
necessary  to  operate  the  mission  payload,  hereafl;er  referred  to  as  the  mission  module. 
STANDARDIZED:  The  bus  will  be  a  common  platform  with  a  standardized  interface,  to 
which  many  different  types  of  mission  modules  will  be  integrated. 

THE  BEST:  System  solutions  must  focus  on  satisfying  the  requirements  and  objectives  of 
the  decision  maker,  which  are  themselves  subject  to  refinement  and  qualification. 

SMALL:  Satellites  employing  this  bus  must  be  in  the  weight  class  of  Pegasus  or 
Lockheed  Martin  launch  vehicles. 

TACTICAL:  Satellites  employing  this  bus  will  be  used  for  tactical  misisons. 

The  fundamental  objectives  are  shown  below  in  Figure  1 . 
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Objectives  that  occupy  the  same  level  of  the  overall  objective  hierarchy  will  be  compared 
to  each  other. 
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Minimize  Cost: 

Cost  is  broken  down  into  monetary  value  and  time. 


1 .  Minimize  $:  The  performance  of  each  monetary  cost  objective  may  not  be 
measured  in  actual  dollars;  for  some  objectives  a  proxy  utility  scale  will  describe  the  cost. 
The  main  subobjectives  are: 


a.  Min  RDT&E  Cost:  Includes  all  non-recurring  costs  from  the  beginning  of  the 
project  to  the  production  effort. 

b.  Min  Bus  Production  Cost:  The  cost  of  manufacturing  the  final  product. 

c.  Min  Retirement  Cost:  At  the  end  of  its  mission  and/or  design  life,  the  satellite  will 
be  retired  via  reentry  into  the  atmosphere,  natural  orbital  decay,  or  placing  it  in  a 
“retirement”  orbit.  The  method  of  retirement  will  dictate  the  cost. 

d.  Operations  Cost:  This  cost  can  be  divided  into  pre-  and  post-launch  costs. 


MINIMIZE 

RDT&E  COST 

MINIMIZE  BUS 

PRODUCTION  COST 

MINIMIZE 

RETIREMENT  COST 

MINIMIZE 

OPERATIONS  COST 

MINIMIZE 

RDT&E  COST 

MINIMIZE  BUS 
PRODUCTION  COST 

MINIMIZE 

RETIREMENT  COST 

MINIMIZE 

OPERATIONS  COST 

(1)  Minimize  Pre-Launch  Operations  Cost.  This  is  the  sum  of  all  ground  expenditures 
necessary  to  prepare  the  satellite  for  launch.  The  subobjectives  for  this  cost  are: 


(a)  Minimize  Cost  of  Mission  Module  Integration  and  System  Test  This  cost  covers  all 
efforts  to  mate  the  mission  module  to  the  bus,  and  to  test  the  integrated  satellite.  There 
are  various  manpower,  equipment,  software,  and  overhead  costs  associated  with 
coimecting  the  power,  signal,  thermal  and  structural  interfaces.  The  testing  effort  includes 
all  actions  to  ensure  the  integrated  satellite  is  ready  to  be  shipped  for  launch. 


(b)  Minimize  Cost  of  Storage,  Handling,  and  Transportation:  Includes  facilities, 
equipment,  special  procedures,  manpower  and  overhead. 

(c)  Minimize  Cost  of  Maintenance  :  There  are  various  costs  associated  with  maintaining 
MODSAT  hardware  and  software,  including  manpower,  spares,  and  suppUes.  This  covers 
both  periodic  maintenance  and  repairs. 

(d)  Minimize  Cost  of  Launch  Integration  and  Test :  This  covers  all  efforts  to  mate  the 
satellite  to  the  launch  vehicle,  and  to  test  the  loaded  rocket. 
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(2)  Minimize  Cost  of  Telemetry,  Tracking,  and  Commanding:  This  cost  covers  all 
operational  expenditures  for  tracking,  commanding,  and  maintaining  the  orbiting  satellite. 
Elements  of  TT&C  include  ground  segment  hardware  and  software,  satellite  operations 
personnel,  and  communications  and  data  flow  operations. 


Minimize  Time  to  Full  Rate  Production:  The  time  required  to  achieve  full  rate 
production  of  the  bus  should  be  minimized. 


MINIMIZE 

$ 

MIN.  TIME  TO  FULL 

RATE  PRODUCTION 

MINIMIZE 

$ 

MIN.  TIME  TO  FULL 

RATE  PRODUCTION 
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Maximize  Tactical  Responsiveness 

The  bus  is  intended  for  tactical  applications.  Thus,  responsiveness  is  a  primary 
objective.  Satellites  using  this  bus  must  be  able  to  respond  quickly  to  rapidly  generated 
needs  and  mission  requirements. 

1.  Minimize  Preparation  Time  to  Launch:  This  time  interval  begins  with  the  demand  for  a 
particular  mission,  and  ends  with  the  delivery  of  the  satellite  for  launch  vehicle  integration. 

2.  Minimize  Data  Latency:  Data  latency  refers  to  the  time  between  mission  data  collection 
and  reception  by  the  user  in  unusable  form.  This  objective  intends  to  capture  the 
differences  in  data  processing,  down-link,  and  delivery  architecture. 

Maximize  Capability  For  Tactical  Maneuvers:  The  satellite  may  be  called  on  to  perform 
changes  in  station  /  inclination  in  response  to  tactical  mission  needs.  This  subobjective 
covers  the  satellite’s  slew  capability  in  response  to  different  targeting  needs. 


MINIMIZE  PREPARATION 

TIME  TO  LAUNCH 

MINIMIZE 

DATA  LATENCY 

MAXIMIZE  CAPABILITY 

FOR  TAC.  MANEUVERS 

MINIMIZE  PREPARATION 

TIME  TO  LAUNCH 

MINIMIZE 

DATA  LATENCY 

MAXIMIZE  CAPABILITY 

FOR  TAC.  MANEUVERS 

Maximize  Availability 

A  sound  system  design  will  attempt  to  maximize  on-orbit  availability. 


1 .  Max  Reliability:  For  the  purposes  of  this  study,  reliability  refers  to  the  probability 
that,  given  a  non-hostile  environment,  the  bus  will  be  able  to  perform  its  primary  mission 
of  supporting  the  mission  module  at  a  given  point  in  its  lifetime.  It  is  a  measure  of  the 
hardness  of  the  bus  to  the  natural  space  environment  over  the  satellite’s  lifetime,  within  a 
specified  confidence  level 

2.  Maximize  Survivability:  Survivability  refers  to  the  ability  of  the  system  to  perform 
its  intended  mission  after  exposure  to  stressing  environments  created  by  enemy  or  hostile 
agent. 
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MAXIMIZE 

RELIABILITY 

MAXIMIZE 

SURVIVABILITY 

MAXIMIZE 

RELIABILITY 

MAXIMIZE 

SURVIVABILITY 

Minimize  Program  Risk 

Program  risk  refers  to  potential  for  elements  of  the  program  to  fail  to  come 
together  as  planned.  Risk  can  be  assessed  in  the  areas  of  cost,  schedule,  and  performance. 


1.  Cost  Risk:  Each  system  development  program  has  cost  risk,  in  that  the  predicted  life 
cycle  costs  or  individual  elements  of  the  cost  may  be  much  higher  than  planned.  In  a 
sense,  cost  risk  is  a  measure  of  the  lack  of  confidence  in  the  cost  estimates. 

2.  Schedule  Risk:  Schedule  risk  refers  to  the  potential  for  expensive,  unforeseen  slips  in 
the  development  schedule. 

3.  Performance  Risk:  There  is  a  chance  that  some  technological  aspect  of  the  system,  be  it 
hardware  or  software,  will  not  work  as  well  as  planned.  This  usually  depends  on  the 
maturity  of  the  technology  in  question. 


COST 

SCHEDULE 

PERFORMACE 

RISK 

RISK 

RISK 

SCHEDULE 

RISK 

PERFORMACE 

RISK 

Maximize  Mission  Utility 

Mission  utility  refers  to  the  ability  of  the  bus  to  accommodate  a  range  of  different 
missions  modules.  In  other  words,  it  is  a  way  of  quantifying  how  well  the  bus  performs  its 
role  of  being  generic  and  standard.  The  larger  the  range  of  possible  missions,  the  higher 
the  mission  utility.  Mission  utility  is  supported  by  the  various  aspects  of  bus  performance, 
such  as  pointing  accuracy  and  available  power.  In  other  words,  if  more  performance 
capability  is  built  into  the  bus,  more  mission  types  can  be  accommodated.  Thus,  several 
performance  subobjectives  were  adopted,  in  addition  to  the  obvious  desire  to  maximize 
the  available  weight  and  volume  for  the  mission  module. 
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1  •  Max  Pointing  Accuracy:  Many  space  mission  applications  require  a  great  deal  of 
spacecraft  pointing  accuracy,  for  precise  pointing  and  orientation  of  sensing  instruments. 

2.  Max  Orbital  Accuracy:  The  satellite  must  be  able  to  maintain  its  intended  orbit,  in 
order  to  be  available  for  its  intended  applications. 

3.  Max  Data  Storage:  Various  missions  may  require  the  spacecraft  processor  to 
temporarily  store  mission  data,  for  later  transmission. 

4.  Max  Data  Down-link  Rate:  Although  the  bus  must  be  compatible  with  the  Air 
Force  Satellite  Control  Network  (AFSCN),  some  missions  may  require  a  higher  data 
downlink  rate  than  can  be  accommodated  with  AFSCN  compatible  communications 
equipment.  Systems  solutions  that  provide  for  higher  rates  would  be  more  attractive,  all 
other  factors  being  equal. 

5.  Max  Average  Mission  Module  Power:  This  objective  strives  to  maximize  the 
amount  of  power,  on  average,  that  the  bus  makes  available  to  the  mission  module.  A 
survey  of  existing  LEO  military  satellites  reveals  that  their  power  requirements  cover  a 
wide  range. 

6.  Max  Peak  Mission  Module  Power:  Some  mission  applications  will  require  large 

amounts  of  power  during  peak  operations.  The  bus  must  be  able  to  handle  peak 

demands  which  can  greatly  exceed  the  average  demand. 

7.  Max  Allowable  Mission  Module  Weight:  One  of  the  main  design  goals  of  this 
study  is  a  lightweight  bus  which  allows  for  the  heaviest  possible  mission  module. 

The  amount  of  allowable  mission  module  weight  is  determined  by  subtracting  the  bus 
weight  from  the  total  allowable  weight,  which  depends  on  the  launch  vehicle  and  the 
selected  orbit. 

8.  Max  Allowable  Mission  Module  Volume:  This  subobjective  is  met  by  minimizing 
the  volume  of  the  bus.  The  amount  of  allowable  mission  module  volume  is  determined  by 
subtracting  the  bus  volume  from  the  total  allowable  volume,  which  depends  on  the  volume 
and  dimensions  of  the  launch  vehicle  payload  fairing. 

9.  Max  Adaptability:  This  subobjective  is  intended  to  capture  the  desire  for  flexibility 
of  design,  and  adaptability  to  changing  mission  requirements.  The  ability  to  add  needed 
capability  or  remove  excess  capability  is  valued,  but  consideration  must  be  given  to 
minimizing  the  amount  of  engineering  which  must  be  apphed  to  the  integration  effort. 

10.  Min  Thermal  Transfer:  It  is  necessary  to  limit  the  amount  of  heat  energy  which 
crosses  the  interface  to  the  mission  module.  Mission  instruments  can  be  very  sensitive  to 
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heat.  Consideration  must  be  given  to  the  highly  dynamic  nature  of  a  spacecraft  thermal 
environment. 


Fundamental  Objectives 


MINIMIZE 


MAXIMIZE  MAXIMIZE  MINIMIZE  MAXIMIZE  MIS. 

RESPONSIVENESS  AVAILABLITY  PROGRAM  RISK  UTILITY 


APPENDIX  B:  STRUCTURES  AND  MECHANISMS 


Structure’s  Trade  Study  (Phase  I) 

1.1  Calculating  maximum  volume  for  the  payload  bay 

payloadbayht  :=  34.27in  payload_bay_dia:=  39.5in 

volume_payIoad_bay:=  •7r  payload_bay_ht 

5  3 

volume_payload_bay=  6.88176- 10  -cm 


1.2  Calculating  surface  area  for  the  payload  bay 

/  payload_bay_dia\^ 


area_payload_bay  :=  2- 


area_payload_bay  =  4.32483 1  o'*  •  cnr 


71  payloadbaydiapayloadbayht 


2.1  Calculating  maximum  volume  and  area  for  a  hexagon 


num  sides  =  6 


polygon_rad- 


payload_bay_dia 


central_angle  = 


2’ 71 


num  sides 


central_angle=  60  •  deg 


alpha  := 


centralangle 


alpha  =  30 -deg 


polygon_base:=  2polygon_radsin(alpha)  polygon_base=50.l65'cm 


polygon_cntr_to_base = 


(polygon.basej  coK^pha) 


polygon_cntr_to_base=  43.444iecm 


polygonareabottom = 


polygon  base  p^iyg^jj  j5asenum_sides 


polygon_area_bottora=  6.53813 10^  -cm^ 
volume_polygon  =  polygon_area_bottonpayload_bay_ht 

volume_polygon  =  5 .69 1 1 7  •  1 0^  •  cm^ 

polygon_perimeter=  num_sidespolygon_base  polygon_perimetei=  300.99- cm 

area_polygon  =  polygon_perimet«payload_bay_ht+  2polygon_area_bottom 
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area_j)olygoiT=  3 .92762 1 0  -cm 

2.2  Total  length  of  all  edges  of  a  Hexagon 

tot_length=  2polygon_perimeter+  nuni_sidespayIoad_bay_ht 

tot  length  =  1.12425*10^  *cm 


3.1  Calculating  maximum  volume  and  area  for  the  sphere 


sphere_dia  =  payload_bay_ht 

volume_sphere=  3.45336 10^  -cin 
area_sphere=2.380381(f  *0111 


volume_sphere:= 


4  n  I  /sphere_dia’ 


2 

area_sphere  =  n-  spheredia 


3.2  Total  length  of  all  edges  of  a  sphere 

num_rings  =  1 0  tot_length_sphere  =  num_rings(  n  ■  spheredia) 

tot_length_sphere=  2.73462 10^  *  cm 


4.1  Calculating  maximum  volume  and  area  for  a  rectangle 

_ ;  _ .  payload_bay_dia 


num  sides  :=  4 


polygonrad: 


central_angle  = 


num  sides 


centraI_angleF=  90  •  deg 


alpha : 


centralangle 


alpha  =  45 -deg 


polygon_base :  =  2-  polygon_rad  sin(  alpha)  polygonbase  =  70.94402  cm 

,  ,  /polygon  base\  ^  , 

polygon_cntr_to_base  =  I - - - I  •  cot(  alpha) 


polygon_cntr_to_base=  35.47201*  cm 

,  num  sides  polygon  base  polygon  cntr  to  base 

polygon_area_bottom= - - 


polygon_area_bottom=  5.03305 10^  •  cm^ 
volume_polygon  =  polygon_area_bottompayload_bay_ht 

voliime_polygoiT4.38l06l0^  -cm^ 
polygon_perimeter  =  num_sides  polygon_base 
polygon_perimetei=  283.77609  cm 

area_polygon  =  polygon jperimeteipayload_bay_ht+  2polygon_area_bottom 
area_polygon=  3 .47676 1 •  cm^ 
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4.2  Total  length  of  all  edges  of  a  rectangle 

totJength_rectangle=  2polygon_perimeter+  numsidespayloadbayht 

totlengthrectanglcF  9l5.73539-cm 


5.1  Calculating  volume  and  surface  area  for  a  cylinder 

,.11-  .  ...  /cylinder  diaii 

cylinder_dia:=  payloadbaydia  volumecyhnder-  “ 

volume  cylindeF  6.88176 10^  -cm^ 


area_cylinder  :=  2- 


'  '  2 

/  cylinder_dia:i 

\  2  / 

v4 


+  n  cylinder  diapayload  bay  ht 


area_cylinder=  4.32483  -cm' 


2 

•7t  payload  bay  ht 


5.2  Total  length  of  all  edges  of  a  cylinder 

num_rings  =  10  tot_Iength_cylindei^  2  jr  cylinder_dia+  num_ringspayload_bay_ht 

tot_length_cylindei=  l . 50085 1 -cm 


Structure's  Pairwise  Comparison 

Modularity  and  subcomponent  supportability _ 


Cage 

Truss 

Blocks 

Shelf 

Drawer 

Total 

Cage 

3 

3 

4 

3 

13 

Truss 

1 

1 

1 

1 

4 

Blocks 

1 

3 

3 

2 

9 

Shelf 

0 

3 

1 

1 

5 

Drawer 

1 

3 

2 

3 

9 

Material  usage 


Cage 

Truss 

Blocks 

Shelf 

Drawer 

Total 

Cage 

1 

3 

2 

3 

9 

Truss 

3 

4 

3 

4 

14 

Blocks 

1 

0 

1 

1 

3 

Shelf 

2 

1 

3 

3 

9 

Drawer 

1 

0 

3 

1 

5 
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Structural  Rigidity 


Cage 

Truss 

Blocks 

Shelf 

Drawer 

Total 

Cage 

1 

0 

2 

2 

5 

Truss 

3 

1 

3 

3 

10 

Blocks 

4 

3 

4 

4 

15 

Shelf 

2 

1 

0 

2 

3 

Drawer 

2 

1 

0 

2 

5 

Manufacturing 


Cage 

Truss 

Blocks 

Shelf 

Drawer 

Total 

Cage 

3 

4 

3 

4 

14 

Truss 

1 

4 

3 

3 

11 

Blocks 

0 

0 

1 

2 

3 

Shelf 

1 

1 

3 

3 

8 

Drawer 

0 

1 

2 

1 

4 

Overall  pairwise  comparison  results 


Modularity 

Materials 

Usage 

Structural 

Rigidity 

Manufacturing 

Total 

Cage 

13 

9 

5 

14 

41 

Truss 

4 

14 

10 

11 

38 

Blocks 

9 

3 

15 

3 

30 

Shelf 

5 

9 

3 

8 

25 

Drawer 

9 

5 

5 

4 

23 

Obtaining  the  optimum  beam  diameter  and  thickness 


m 

gravity  :=  9.81- - 

factor_safety:=  1.6  axial_^:=  13 

sec^ 

kg- 

T.  o  sec 

E  :=  72-l(f- - 

9 

Per  :=  225  kg  gravity(factor_safety axial 

m 

Per  =  4.5910810'*  kg  m  sec  ^  <»Max  loading  Conditions 

beam  radius  =  — cm 
1  100 


i  1..  150 


<--Beam  radius  0.0  to  1.5  cm 


I_beam:  backing  out  this  information  so  that  beam  thickness  can  be 
calculated  for  each  I  beam  case. 


Ibeam. 

temp_thick  .  =  — - - - — — 

n  ■  ^beam_radiusj 


<-Find  all  possible  thicknesses 


beam  thicl^j  :=  I  temp  thicl^  j- cm  if  beam_radiu^>temp_thicl|  j 
0  cm  if  temp_thici|  j>beam_radiuSj 


Because  the  solved  thicknesses  may  be  greater  than  beam  radius,  the 
above  relationship  filters  those  conditions,  setting  them  to  0. 
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Beam  thicknesses 


beam  thick 


temp_radiu5  j  = 


volum^j  :=  ^temp  radiu^  jj  ■%  -  ^temp^radiu^  j  -  beam  thicl^  j j  -n 


volume 
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APPENDIX  C:  THERMAL  ANALYSIS  OF  THE  INTERFACE  BLANKET 


Q_dot  =  15  watt 


,  ,  watt 

k  aluminum-  173- - 


k  woven  insulation^  0.038 


mK 

i  :=  228,232.. 338  T_intemal_s^  =  i-K  j  =  i..  lo 

L_woven_insulation  =  j  •  cm  A_woven_insulatiom  ( 43 .63  cm)^-  v. 


watt 

m-K 


T  woven  insulation.  = 
i=J 


Qdot  Lwoveninsulation 
\k_woven_insulatioiA_woven_insulatioii 


+  T  internal  sat 

—  —  1 


L_aluminum-  i  cm  A_aluminum=  A_woven_insulation 

_  .  .  /  Q_dot  L_aluminum  \  ^  . 

T_interface_plate .  -  -  +  T_woven_msulation. 

’J  \k_aluminumA_aluminun5l  ‘’J 
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